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

[Roland McGrath <roland at redhat dot com>]

> 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.

> 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)?

> So, is my ALLOC & EXEC expectation valid?  If it's too strict, is any 
> ALLOC section kosher, and GRUB modules are erroneous, or is any section 
> at all kosher?

I can't see how a non-ALLOC section case could be kosher.  But we need to
look at what's going on in the actual cases to get more clear on it.


Thanks,
Roland