This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: A 48 byte kernel module/cfi load mystery
On Fri, 2010-07-02 at 11:19 -0700, Roland McGrath wrote:
> Kernel modules are relocatable objects, so those addresses you see are as
> placed by libdwfl. If you pass them to dwfl_module_relocate_address you
> will get their section-relative offsets.
Thanks for the explanation. In retrospect it is all so obvious :)
> Let's take an example object:
>
> $ eu-readelf -S /usr/lib/debug/lib/modules/2.6.33.5-124.fc13.x86_64/kernel/fs/ext2/ext2.ko.debug
> There are 44 section headers, starting at offset 0x245418:
>
> Section Headers:
> [Nr] Name Type Addr Off Size ES Flags Lk Inf Al
> [ 0] NULL 0000000000000000 00000000 00000000 0 0 0 0
> * [ 1] .note.gnu.build-id NOTE 0000000000000000 00000040 00000024 0 A 0 0 4
> * [ 2] .text NOBITS 0000000000000000 00000064 00009c8c 0 AX 0 0 4
> <...>
>
> Since the allocated section before it has size 0x24, that will be the
> address where .text is placed.
And the 0x48 on x86_64 was similar, but needed a bit more because of
address alignements.
> I've just changed eu-readelf (for the eventual 0.149) to print FDE
> addresses like it does others from DWARF, so (without -N) it shows:
>
> [ 18] FDE length=52 cie=[ 0]
> CIE_pointer: 0
> initial_location: .text+000000000000000000 <ext2_bg_has_super>
> address_range: 0x5d
>
> I hope that helps avoid future confusion about this.
Yes, that would have made the issue pretty clear. Thanks.
I changed the systemtap translator to keep the .debug_frame FDE initial
locations (the synthetic .debug_frame_hdr) on a per section basis,
including a section load offset that the runtime unwinder uses to arrive
at the correct relative address.
For now, commit 4d83bd, only for the "magic sections", but will change
to track them accurately for all sections covered.
Cheers,
Mark