RFC: Add DT_GNU_DEBUG

[H.J. Lu]

On Tue, Aug 3, 2021 at 11:12 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Daniel Walker:
>
> > On Mon, Aug 02, 2021 at 06:10:55AM -0700, H.J. Lu wrote:
> >> On Sun, Aug 1, 2021 at 10:22 PM Florian Weimer <fweimer@redhat.com> wrote:
> >> >
> >> > * H. J. Lu:
> >> >
> >> > > On Wed, Jul 28, 2021 at 1:04 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >> > >> > Do you want to drive this, or should I ? It looks like you know the people
> >> > >> > involved better than I do.
> >> > >> >
> >> > >>
> >> > >> https://groups.google.com/g/generic-abi/c/1ngxmSwrafc
> >> > >>
> >> > >
> >> > > I don't think the gABI community is interested in a new debug dynamic
> >> > > tag.  I propose DT_GNU_DEBUG:
> >> > >
> >> > > #define DT_GNU_DEBUG   0x6ffffff8
> >> > >
> >> > > for the address of a pointer which will be filled by the dynamic
> >> > > linker.  Linker should
> >> > > add the DT_GNU_DEBUG entry to executable's dynamic section.
> >> > >
> >> > > BTW, we have a choice.  DT_GNU_DEBUG can be readonly or readonly after
> >> > > relocation, like DT_DEBUG.
> >> >
> >> > What about adding DT_DEBUG_SIZE, specifying the size of the data pointed
> >> > to by DT_DEBUG?
> >>
> >> It works if we don't need to support static executables.
> >>
> >> > Perhaps the gABI folks are interested in that, too?  I think it's worth
> >> > a try.  If the answer is “no”, we can still add DT_GNU_DEBUG_SIZE to the
> >> > GNU ABI.
> >>
> >> I did.  I didn't get any feedback.
> >
> > So no feedback equal "not interested" ?
>
> I think the issue is that the struct already has a version field.
>
> It's only a problem for us because we have architectures with copy
> relocations *and* have exposed _r_debug as a public symbol.  However, we
> can do what we did for _sys_errlist in the past (new symbol versions for
> each size change), so it's not a real blocker.

No, copy relocation doesn't work:

https://sourceware.org/bugzilla/show_bug.cgi?id=28130

I want to get rid of copy relocation and keep _r_debug only for existing
broken binaries.   The new interface will provide an access function to
get the address of internal data in ld.so.

> I suppose the easiest way forward would be to grow _r_debug this way,
> bump the version field past Solaris' version, add the Solaris members
> (possibly with dummy values), and add our own new stuff afterwards.
>
> Thanks,
> Florian
>


-- 
H.J.