|
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.