Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87zg7mjz2n.fsf@oldenburg.str.redhat.com>
Date: Wed, 05 Apr 2023 14:25:20 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Re: [PATCH v9 0/13] implement dlmem() function (fwd)

* Rich Felker:

> On Wed, Apr 05, 2023 at 02:13:16PM +0200, Florian Weimer wrote:
>> * Rich Felker:
>> 
>> > Well this is disturbing. We probably need to fix gcc here (and a lot
>> > of code in the wild may be broken) because musl has no such locking
>> > where it doesn't belong.
>> 
>> We have a helper function in glibc (_dl_find_object) that replaces all
>> the previous object traversal logic and caching in libgcc, so it's no
>> longer an issue with current gcc and glibc.
>
> Does gcc automatically detect and use this if available? What gcc
> versions does that cover? We could certainly add it, but I suspect
> coverage will be incomplete... :/

It's using a macro from <dlfcn.h> as a proxy to indicate libc support:

+  /* Use DLFO_STRUCT_HAS_EH_DBASE as a proxy for the existence of a glibc-style
+     _dl_find_object function.  */
+#ifdef DLFO_STRUCT_HAS_EH_DBASE

It's not dependent upon __GLIBC__.

>> Unfortunately that means that the generic dl_iterate_phdr code will
>> be fixed by adding its own locking.
>
> Not sure why that's unfortunate; it's what it should have been doing
> all along.

I missed a negation.  I meant that It's unlikely that it's going to be
fixed, unless you write a patch yourself. 8->

Thanks,
Florian

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.