Re: [RFC PATCH 0/3] implement dlmopen hooks for gdb

[Carlos O'Donell via Libc-alpha <libc-alpha@sourceware.org>]

On 9/22/20 1:37 PM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> On 9/22/20 1:06 PM, Florian Weimer wrote:
>>> * Carlos O'Donell via Libc-alpha:
>>>
>>>> Your next step would be to export the symbol via Versions at the current
>>>> symbol node GLIBC_2.32 (soon to be GLIBC_2.33).
>>>
>>> Can we create a new GLIBC_DEBUG symbol versions for symbols which are
>>> not intended to be used for run-time linking?
>>>
>>> The idea is that consumers will have deal with the absence of these
>>> symbols anyway, so we just need one symbol version that does not depend
>>> on the glibc version for this.  Dependency management considerations
>>> (that apply to symbols with run-time linking) do not come into play here.
>>
>> I don't object to GLIBC_DEBUG, like GLIBC_PRIVATE it can be considered
>> a transient ABI that is valid only for a major release?
> 
> No, unlike GLIBC_PRIVATE, you can assume that if a GLIBC_DEBUG symbol is
> there (and perhaps has the documented size), it has the documented
> semantics.  But you can't assume that it is present.
> 
> The semantics of GLIBC_PRIVATE symbols can change arbitrarily, even
> between builds.

Yes, absolutely, I agree completely, for it to be useful the semantics
have to be:

- If you detect a given symbol foo@GLIBC_DEBUG, then the feature is
  present and has the semantics you expect.

- If you want new semantics then you need to make a foo2@GLIBC_DEBUG
  with the new semantics.

What are the runtime semantics of the symbol? How do you access it?

-- 
Cheers,
Carlos.