linux-kernel - Re: perf probe line numbers + CONFIG_DEBUG_INFO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 18 Apr 2018 23:03:01 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jiri Olsa <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        systemtap@...rceware.org, Mark Wielaard <mark@...mp.org>
Subject: Re: perf probe line numbers + CONFIG_DEBUG_INFO_SPLIT=y

On Wed, 18 Apr 2018 12:23:43 +0900
Masami Hiramatsu <mhiramat@...nel.org> wrote:

> Hi Arnaldo,
> 
> On Tue, 17 Apr 2018 14:47:01 -0300
> Arnaldo Carvalho de Melo <acme@...nel.org> wrote:
> 
> > Hi Masami,
> > 
> > 	I just tried building the kernel using:
> > 
> > CONFIG_DEBUG_INFO=y
> > # CONFIG_DEBUG_INFO_REDUCED is not set
> > CONFIG_DEBUG_INFO_SPLIT=y
> > # CONFIG_DEBUG_INFO_DWARF4 is not set
> 
> Yeah, this is what I have to solve...
> 
> > 
> > 	that info split looked interesting, and I thought that since we
> > use elfutils we'd get that for free somehow, so I tried getname_flags
> > and got the output at the end of this message, with these artifacts:
> > 
> > 1) the function signature doesn't appear at the start of the '-L
> > getname_flags' output
> > 
> > 2) offsets are not calculated, just the line numbers in fs/namei.c (it
> > matches the first line :130 with the first line number.
> 
> I think we need to use elfutils with different way, maybe passing
> correct debuginfo file, instead of vmlinux.
> Oh, did you got the source code lines? I'll try to reproduce it.

OK, I found this gcc article what actually happen if we enable that option.

https://gcc.gnu.org/wiki/DebugFission

With CONFIG_DEBUG_INFO_SPLIT=y, we will get very limited debuginfo
in vmlinux. It seems only have address-to-line information in
vmlinux, and the main DIE tree will be stored in .dwo files,
which is generated for each .o file.

That is why you could get source lines by "perf probe -L", but
failed to get variables etc. by "perf probe -a". (Note that perf-probe
always search DIE tree for finding correct "subprogram"(function) info.)


$ eu-readelf --debug-dump=info ~/kbin/linux.x86_64/vmlinux
DWARF section [63] '.debug_info' at offset 0x23f1db0:
 [Offset]
 Compilation unit at offset 0:
 Version: 2, Abbreviation section offset: 0, Address size: 8, Offset size: 4
 [     b]  compile_unit
           stmt_list            (data4) 0
           ranges               (data4) range list [     0]
           name                 (strp) "/home/mhiramat/ksrc/linux/arch/x86/kerne
l/head_64.S"
           comp_dir             (strp) "/home/mhiramat/kbin/linux.x86_64"
           producer             (strp) "GNU AS 2.27"
           language             (data2) Mips_Assembler (32769)
 Compilation unit at offset 34:
 Version: 4, Abbreviation section offset: 18, Address size: 8, Offset size: 4
 [    2d]  compile_unit
           ranges               (sec_offset) range list [   3b0]
           low_pc               (addr) 000000000000000000 <irq_stack_union>
           stmt_list            (sec_offset) 409
           lo_user+0x130        (strp) "arch/x86/kernel/head64.dwo"
           comp_dir             (strp) "/home/mhiramat/kbin/linux.x86_64"
           lo_user+0x134        (flag_present) yes
 Compilation unit at offset 86:
 Version: 4, Abbreviation section offset: 47, Address size: 8, Offset size: 4
 [    61]  compile_unit
           ranges               (sec_offset) range list [   470]
           low_pc               (addr) 000000000000000000 <irq_stack_union>
           stmt_list            (sec_offset) 4388
           lo_user+0x130        (strp) "arch/x86/kernel/ebda.dwo"
           comp_dir             (strp) "/home/mhiramat/kbin/linux.x86_64"
           lo_user+0x134        (flag_present) yes

It shows where we can see the .dwo file.
However, it seems elfutils doesn't support dwo.

$ eu-readelf --debug-dump=info ~/kbin/linux.x86_64/fs/namei.dwo 
eu-readelf: cannot get debug context descriptor: No DWARF information found

As above gcc article said, the section name has been changed.

$ eu-readelf -S ~/kbin/linux.x86_64/fs/namei.dwo There are 10 section headers, starting at offset 0x49440:

Section Headers:
[Nr] Name                 Type         Addr             Off      Size     ES Flags Lk Inf Al
[ 0]                      NULL         0000000000000000 00000000 00000000  0        0   0  0
[ 1] .debug_info.dwo      PROGBITS     0000000000000000 00000040 000252d7  0 E      0   0  1
[ 2] .debug_abbrev.dwo    PROGBITS     0000000000000000 00025317 00000f2f  0 E      0   0  1
[ 3] .debug_loc.dwo       PROGBITS     0000000000000000 00026246 00004f9b  0 E      0   0  1


And I found below description in systemtap document(man/error::dwarf.7stap).
===
debuginfo configuration
Some tools may generate debuginfo that is unsupported by systemtap, such
as the linux kernel CONFIG_DEBUG_INFO_SPLIT (\f2.dwo\f1 files) option.
Stick with plain ELF/DWARF (optinally split, Fedora-style), if possible.
===

So, it seems that elfutils may not support this split debuginfo yet.

Thank you,

-- 
Masami Hiramatsu <mhiramat@...nel.org>