RE: [EXTERNAL] Re: DWARF Debug Info Relocations (.debug_str STRP references)

[Michael Matz <matz@suse.de>]

Hello,

On Tue, 1 Dec 2020, Bill Messmer via Gcc wrote:

> Thank you very much for the help.  I was so fixated on the fact that the 
> .rela.debug* sections were there that I didn't pay attention to the 
> e_type in the ELF header.  Apparently, neither did the library that I 
> was using to parse the DWARF data.
> 
> Interestingly, I have seen other non-RedHat kernel debug images where 
> the kernel is ET_EXEC

vmlinux is always final-linked.

> and there are still .rela.debug* sections present 
> in the image.

Depending on configuration vmlinux is linked with --emit-relocs, which 
causes all relocations, no matter if applied or not, to also be emitted in 
a final link.  That has its uses, but it also confuses most tools, as 
they blindly apply relocations again, even if they aren't from loadable 
segments.

As not much other software uses --emit-relocs, and even in linux it's 
optional and non-default you see these confused tools occuring in the wild 
instead of being fixed.


Ciao,
Michael.

> Though the effect of applying those relocs has always 
> been nil (the data in the original .debug* section is already the same 
> as what the .rela.debug* section indicates to alter).
> 
> Sincerely,
> 
> Bill Messmer
> 
> -----Original Message-----
> From: Mark Wielaard <mark@klomp.org> 
> Sent: Monday, November 30, 2020 6:39 PM
> To: Bill Messmer <wmessmer@microsoft.com>
> Cc: gcc@gcc.gnu.org
> Subject: Re: [EXTERNAL] Re: DWARF Debug Info Relocations (.debug_str STRP references)
> 
> Hi Bill,
> 
> On Mon, Nov 30, 2020 at 10:22:34PM +0000, Bill Messmer wrote:
> 
> > I'm still a bit confused here.  And the reason I ask this is because I 
> > open this particular vmlinux image with an OSS ELF/DWARF library...  
> > which gives me the *WRONG* names for various DWARF DIEs.
> > I stepped through the library...  and the reason the names are wrong 
> > is because the library applies all of the relocations in 
> > .rela.debug_info to the sections it opens.  I thought there might be a 
> > bug in the library somewhere, so I started down looking at the DWARF 
> > data with standard Linux tools and in hex dumps...  and it seemed 
> > incorrect to my -- admittedly limited -- understanding...
> >
> > Yes, I am using llvm-dwarfdump to textualize the DWARF data
> > (llvm-dwarfdump-10 --verbose vmlinux) and I would assume(?) this 
> > applies the relocations as necessary.  And I am using readelf to get 
> > the section data (readelf -S vmlinux) and the relocation data (readelf 
> > -r vmlinuix); however, the hex data I show is just a flat hexdump of 
> > the image (hexdump -C vmlinux -n ... -s ...).
> 
> I traced your steps and did the same on a local vmlinux copy and got the same results as you. That didn't make sense to me. Till I realized my original assumption, that the vmlinux image, like kernel modules were partially linked and so ET_REL files that still needed relocation applied, seemed wrong. The vmlinux file isn't actually ET_REL, but it is ET_EXEC (see readelf -h vmlinux). In which case other tools don't apply the relocations. And so your observation is correct. The offset to the .debug_str table is right in the .debug_info section, the relocations are meaningless. That is surprising.
> 
> > Either both that library and my understanding are incorrect, there is 
> > something wrong with that relocation data, or it flat isn't supposed 
> > to be applied...
> 
> It is the last thing, the aren't supposed to be applied because it is an ET_EXEC file (which isn't supposed to have .rela.debug sections, but apparently has).
> 
> > I also tried what you suggested "eu-strip -- reloc-debug-sections vmlinux -f stripped" and looked at the resulting output:
> > 
> > "readelf -S stripped" still shows the reloc sections:
> > 
> >       [65] .debug_info       PROGBITS         0000000000000000  00059e50
> >            000000000c458644  0000000000000000           0     0     1
> >       [66] .rela.debug_info  RELA             0000000000000000  0c4b2498
> >            000000001288ae68  0000000000000018   I      78    65     8
> > 
> > And that relocation is still there via "readelf -r stripped":
> 
> Which now also makes sense, because as the --help text says "only relevant for ET_REL files".
> 
> So you did find a real mystery, for some reason the way the vmlinux image is created does get relocations correctly applied, but they (or at least some) are still left behind in the ELF image even though they are no longer needed (and if you do try to use/apply them, you get wrong results). We should probably find out if this happened during the upstream build or during distro packaging.
> 
> Cheers,
> 
> Mark
>