This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Make kernel DWARF unwinder work with ksalr.
Hi Mark,
> Am 25.04.2018 um 14:38 schrieb Mark Wielaard <mark@klomp.org>:
>
> Hi Torsten,
>
> On Tue, 2018-04-24 at 21:30 +0200, Torsten Polle wrote:
>> OK, so the sec_load_offset which we set at translation time from
>>> the
>>> on-disk addresses is "good". But the static_addr of the kernel/_stext
>>> section that is set at runtime based on the _stext symbol gotten from
>>> /proc/kallsyms is off/wrong/unaligned.
>>>
>>> That is surprising.
>>> You are seeing this on i386 and arm64, but not x86_64?
>>>
>>> Could you on those systems grep _stext /proc/kallsyms to see what that
>>> reports as _stext address?
>>>
>>> For me (on x86_64, 3.10.0-862.el7.x86_64) it is:
>>> ffffffff83e00000 T _stext
>>>
>>
>> My test system runs on i386. The results are as follows.
>> objdump reports
>>> c1000358 g .text 00000000 _stext
>>
>> /proc/kallsyms reports
>> ce400358 T _stext
>
> O... Thanks for giving both.
> But that looks like _stext isn't the start of the kernel module/section
> address space.
That’s right.
> I wonder if that might cause other issues.
>
> My understanding is that we relocate against _stext because we assume
> that creates all addresses relative to the vmlinux core memory
> placement. But if _stext isn't at the exact start…
Not it’s not. Please have a look at an excerpt of the output of objdump -x.
vmlinux: file format elf32-i386
vmlinux
architecture: i386, flags 0x00000113:
HAS_RELOC, EXEC_P, HAS_SYMS, D_PAGED
start address 0x01000000
Program Header:
LOAD off 0x00001000 vaddr 0xc1000000 paddr 0x01000000 align 2**12
filesz 0x00b89000 memsz 0x00b89000 flags r-x
LOAD off 0x00b8a000 vaddr 0xc1b89000 paddr 0x01b89000 align 2**12
filesz 0x0018b000 memsz 0x00316000 flags rw-
NOTE off 0x00907c2c vaddr 0xc1906c2c paddr 0x01906c2c align 2**2
filesz 0x00000024 memsz 0x00000024 flags ---
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00906c2c c1000000 01000000 00001000 2**6
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
SYMBOL TABLE:
c1000000 l d .text 00000000 .text
c1000000 g .text 00000000 _text
c1000000 g .text 00000000 startup_32
c1000358 g .text 00000000 _stext
> So we probably also need to look at the exact addresses that
> sec_load_offset and static_addr have in runtime/unwind.c
> (adjustStartLoc). If you could print them out with something like
> _dbug("sec_load_offset: %lx, static_addr: %lx\n",
> s->name, s->sec_load_offset, s->static_addr);
> for the "kernel" case we can be sure whether they really are matched
> with the _stext symbol or the section load address.
I already did that. The values in [1] were taken from log statements
like the one you propose above (cf below once more for reference).
s->static_addr: 0xc9600358
s->sec_load_offset: 0xc1000000
I promised values from /proc/kallsyms.
They are for X86_64
ffffffff810002b8 T _stext
and for ARM64
ffff200008080800 T _stext
> Thanks,
> Mark
Regards,
Torsten
[1] https://sourceware.org/ml/systemtap/2018-q2/msg00028.html