Re: relocation of DW_AT_low_pc against non-exec and/or non-alloc section

[Petr Machata <pmachata at redhat dot com>]

Roland McGrath wrote:
>> The case of non-EXEC is in .rodata of vmlinux.  A single die that comes 
>> from arch/x86/kernel/trampoline_32.S has this property.  So I shift my 
>> understanding of low_pc and high_pc from "we can expect PC to have this 
>> address" to "it's a place in address space".
> 
> I looked at this case.  It's an oddball, but valid.  That code is in
> .rodata because it's not actually run there, but copied to different
> addresses at runtime.  It's a kosher CU from as -g producing line info.
> These "PC" addresses will never map usefully from where a PC really is at
> runtime, but statically it is a kosher and useful mapping from where the
> code appears at its symbol.  i.e., eu-addr2line -e vmlinux trampoline_data+0
> 
> This is sufficiently unusual that it might still warrant a warning.  But if
> it looks otherwise kosher, e.g. is SHF_ALLOC and not SHF_WRITE, it could
> mention "might be nonexecuted code in rodata" or something.  
> 
> Hmm, but looking at the source, it is sometimes in a writable section here
> (.cpuinit.data, depends on kernel config).
> 
> Other than this one case, it seems about as likely that it would be due to
> a build error as to an authentic oddball like this.  But, there is nothing
> technically invalid (or even necessarily "suspicious") about it from a pure
> DWARF perspective.

Thanks for the analysis, will implement this tomorrow.

>> Another case is basically any GRUB module.  These have relocations of 
>> low_pc and high_pc formed against .moddeps, which is non-ALLOC section 
>> (which, if I understand things correctly, means it doesn't end up in 
>> address space at all).
> 
> I'm not sure I found the right things to look at, since I did not find any
> .moddeps sections where I looked.  Can you point me to a particular example
> (rpm id + file name)?

One of the modules was this one:
./i586/gr/ub/grub2-debuginfo-1.98-0.5.20080827svn.fc11.i586/usr/lib/debug/usr/lib/grub2/i386-pc/sleep.mod.debug.bz2

And the relevant message from my locally hacked version:
warning: .rel.debug_info: offset 0x50b: associated section #13 isn't 
SHF_ALLOC.

It tells something different on the branch, I didn't commit this change 
yet, but it should give some sort of diagnostic for that relocation.

Thanks,
PM

Attachment: signature.asc
Description: PGP signature