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 couldmention "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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
