Mark,

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 and there are still .rela.debug* sections present in the 
image.  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 <m...@klomp.org> 
Sent: Monday, November 30, 2020 6:39 PM
To: Bill Messmer <wmess...@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

Reply via email to