[PATCH] ld: ensure build-id is placed near ELF headers

[H.J. Lu]

On Fri, Sep 20, 2024 at 4:54 AM Sam James <sam@gentoo.org> wrote:
>
> Nick Clifton <nickc@redhat.com> writes:
>
> > Hi Andrew,
> >
> >   [Sorry for being so late in responding to your email]
> >
> >> When an executable is built with the --rosegment option GDB is no
> >> longer able to find the build-id of the executable from a core file.
> >
> > For problems like this it really helps if you create a bug report
> > using the Sourceware bugzilla system.  This allows us to track the
> > problem and any discussion surrounding it.  It also means that we
> > can refer to the bug ID in comments in the code.
> >
> > In order to save you time however, I have gone ahead and created
> > a bug report for you:
> >
> >   https://sourceware.org/bugzilla/show_bug.cgi?id=32100
> >
> >> This patch aims to fix this by placing the build-id first.  The
> >> build-id will then be included within the same LOAD-able segment as
> >> the executable content, just as the ELF headers are.  With this patch
> >> in place GDB is once again able to find the build-id from a core
> >> file.
> >
> > Unfortunately that patch breaks the intention of the --rosegment
> > option by restoring two loadable, read-only segments to the executable.
> >
> > Here is an example:
> >
> >   $ cat hello.c
> >
> >   extern int printf (const char *, ...);
> >   int i = 42;
> >   const int * j = & i;
> >   int main (void) { return printf ("hello world %d\n", * j); }
> >
> >   $ gcc -fPIC -Wl,-z,noseparate-code hello.c
> >   $ readelf -lW a.out | grep LOAD
> >
> >   LOAD           0x000000 0x0000000000400000 0x0000000000400000 0x0006d4 0x0006d4 R E 0x1000
> >   LOAD           0x000df8 0x0000000000401df8 0x0000000000401df8 0x000228 0x000230 RW  0x1000
> >
> >   $ gcc -fPIX -Wl,-z,separate-code hello.c
> >   $ readelf -lW a.out | grep LOAD
> >
> >   LOAD           0x000000 0x0000000000400000 0x0000000000400000 0x000510 0x000510 R   0x1000
> >   LOAD           0x001000 0x0000000000401000 0x0000000000401000 0x000155 0x000155 R E 0x1000
> >   LOAD           0x002000 0x0000000000402000 0x0000000000402000 0x0000dc 0x0000dc R   0x1000
> >   LOAD           0x002df8 0x0000000000403df8 0x0000000000403df8 0x000228 0x000230 RW  0x1000
> >
> >   $ gcc -fPIX -Wl,-z,separate-code -Wl,--rosegment hello.c
> >   $ readelf -lW a.out | grep LOAD
> >
> >   LOAD           0x000000 0x0000000000400000 0x0000000000400000 0x00115d 0x00115d R E 0x1000
> >   LOAD           0x002000 0x0000000000402000 0x0000000000402000 0x0002d4 0x0002d4 R   0x1000
> >   LOAD           0x002df8 0x0000000000403df8 0x0000000000403df8 0x000220 0x000228 RW  0x1000
> >
> >   $ gcc -fPIX -Wl,-z,separate-code -Wl,--rosegment hello.c -fuse-ld=patched-linker
> >   $ readelf -lW a.out | grep LOAD
> >
> >   LOAD           0x000000 0x0000000000400000 0x0000000000400000 0x00039c 0x00039c R   0x1000
> >   LOAD           0x001000 0x0000000000401000 0x0000000000401000 0x00015d 0x00015d R E 0x1000
> >   LOAD           0x002000 0x0000000000402000 0x0000000000402000 0x00024c 0x00024c R   0x1000
> >   LOAD           0x002df8 0x0000000000403df8 0x0000000000403df8 0x000220 0x000228 RW  0x1000
> >
> >   (I invented the "-fuse-ld=patched-linker" option to keep the presentation simple.  In
> >   reality I used a full path to a linker built with your proposed patch applied).
> >
> > The section to segment mapping is changed by using --rosegment, but with your patch
> > applied we still get an early read-only segment containing the note sections.
> >
> > I think that what is needed is a patch to move all of the read-only segments to
> > before the read-execute segment.  But this weill need testing.
>
> I'm reading over the rest of the thread, so apologies if this got
> addressed later, but did we add a testcase like this?

Hi Andrew,

Why does GDB need the build-id to be placed close to the ELF header?
Can't GDB read the program header and search for the build-id in PT_NOTE
segment? If GDB needs help, we can add a PT_BUILD_ID segment.

-- 
H.J.