|
|
Message-ID: <CAFS5DSEAf+Qk-i9bzm1Thpv=r_m=-7YPOZ5m=p4=wWxicQw=qA@mail.gmail.com>
Date: Fri, 6 Feb 2026 17:11:03 -0300
From: Luciano Lo Giudice <lmlogiudice@...il.com>
To: Luciano Lo Giudice <lmlogiudice@...il.com>, musl@...ts.openwall.com
Subject: Re: [RFC] Implement the _dl_find_object interface
> i think it makes sense to report the libgcc bug.
> (i'd expect the libgcc maintainers to require the defacto lock
> in libc, however this is not documented currently)
Agreed. The reason I suggested this new interface is that I've seen that in
the past some projects haven't been
receptive to the idea of musl-specific workarounds since detecting this
libc is not as straightforward as they'd like.
Still, I agree it merits reporting this issue.
> note that glibc uses a version check + retry lock-free algorithm
> in _dl_find_object for performane, musl could do this simpler
> as it does not have to deal with dlclose. (e.g. dladdr could be
> lock-free)
Indeed. I personally think musl could use a lightweight RCU scheme for the
dynamic linker, but that's a
discussion for another day.
> this should be in a bits/ header, not generic
I'm OK with this, but there's no bits/header where this would fit nicely.
There's alltypes.h, but putting this
definition there doesn't look good to me. Should I create a new header for
this?
> this does not match the glibc abi/api on arm.
> needs DLFO_STRUCT_HAS_EH_COUNT
> this api must work with static linking
Ack.
(Thanks for the review, btw).
Content of type "text/html" skipped
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.