Created attachment 680556 [details] The script
Created attachment 680557 [details] Error output.
From eu-readelf -N -w, that die is: [1517249] formal_parameter name (strp) "count" decl_file (data1) 1 decl_line (data2) 468 type (ref4) [15095d8] location (sec_offset) location list [577acc] And that location list is: [577acc] 0x0000000000000b85..0x0000000000000bab [ 0] reg1 0x0000000000000bab..0x0000000000000bfb [ 0] reg13 0x0000000000000bfb..0x0000000000000c01 [ 0] GNU_entry_value: [ 0] reg1 [ 3] stack_value 0x0000000000000c01..0x0000000000000c11 [ 0] reg13 I'm not sure why those address ranges are so low. With regular readelf, it reads: 00577acc ffffffff81195705 ffffffff8119572b (DW_OP_reg1 (rdx)) 00577acc ffffffff8119572b ffffffff8119577b (DW_OP_reg13 (r13)) 00577acc ffffffff8119577b ffffffff81195781 (DW_OP_GNU_entry_value: (DW_OP_reg1 (rdx)); DW_OP_stack_value) 00577acc ffffffff81195781 ffffffff81195791 (DW_OP_reg13 (r13)) 00577acc <End of list> The disassembly for the start of sys_write is: 0xffffffff81195700 <+0>: callq 0xffffffff8163d680 <__fentry__> 0xffffffff81195705 <+5>: push %rbp So the debuginfo apparently doesn't start until after the -mfentry addition. Running stap -P (for prologue detection) doesn't change its attempt to probe at the very start, 0xffffffff81195700, which the location list doesn't cover. Frank also asked me if other lines in that function can resolve variables, and it seems so: $ stap -L 'kernel.statement("sys_write@fs/read_write.c:*")' kernel.statement("sys_write@fs/read_write.c:471") $buf:char const* $count:size_t $f:struct fd $ret:ssize_t kernel.statement("sys_write@fs/read_write.c:481") $buf:char const* $count:size_t $f:struct fd $ret:ssize_t
The kernel has started using CFLAGS=-mfentry for its nefarious purposes, which generates DWARF that is more restricted than necessary. The location list for function parameters cover include the -mfentry-caused callq/push pair.
s/cover include/should cover/.
(In reply to comment #2) > From eu-readelf -N -w, that die is: > > [1517249] formal_parameter > name (strp) "count" > decl_file (data1) 1 > decl_line (data2) 468 > type (ref4) [15095d8] > location (sec_offset) location list [577acc] > > And that location list is: > > [577acc] 0x0000000000000b85..0x0000000000000bab [ 0] reg1 > 0x0000000000000bab..0x0000000000000bfb [ 0] reg13 > 0x0000000000000bfb..0x0000000000000c01 [ 0] GNU_entry_value: > [ 0] reg1 > [ 3] stack_value > 0x0000000000000c01..0x0000000000000c11 [ 0] reg13 > > I'm not sure why those address ranges are so low. With regular readelf, it > reads: > > 00577acc ffffffff81195705 ffffffff8119572b (DW_OP_reg1 (rdx)) > 00577acc ffffffff8119572b ffffffff8119577b (DW_OP_reg13 (r13)) > 00577acc ffffffff8119577b ffffffff81195781 (DW_OP_GNU_entry_value: > (DW_OP_reg1 (rdx)); DW_OP_stack_value) > 00577acc ffffffff81195781 ffffffff81195791 (DW_OP_reg13 (r13)) > 00577acc <End of list> eu-readelf prints the "raw" location list entries, which are begin and end address offsets from the base address. The base address is defined either by an earlier selection entry or (more likely) the base address of the compilation unit from which the location list entry is referenced.
Jakub advises this is a known problem in GCC 4.7, reported 2010-10-03. Further testing indicates that this affects gdb too.
(In reply to comment #5) > eu-readelf prints the "raw" location list entries, which are begin and end > address offsets from the base address. The base address is defined either by > an earlier selection entry or (more likely) the base address of the > compilation unit from which the location list entry is referenced. Hmm, OK. IMO that's not very helpful to have raw numbers -- while we're off topic, is there a way to coax elfutils to expand those the way binutils does?
(In reply to comment #7) > Hmm, OK. IMO that's not very helpful to have raw numbers -- while we're off > topic, is there a way to coax elfutils to expand those the way binutils does? There is no direct mapping back from debug_loc to debug_info. And I don't immediately see a good way to know which offset ranges belong to which CU. It seems you have do a full scan of all DIEs in a CU to find the attributes that have a locptr. Which seems a bit expensive. On the other hand we seem to do some of that already anyway to detect unused offset ranges, so maybe we can piggyback on that.
(In reply to comment #8) > (In reply to comment #7) > > Hmm, OK. IMO that's not very helpful to have raw numbers -- while we're off > > topic, is there a way to coax elfutils to expand those the way binutils does? > > There is no direct mapping back from debug_loc to debug_info. And I don't > immediately see a good way to know which offset ranges belong to which CU. > It seems you have do a full scan of all DIEs in a CU to find the attributes > that have a locptr. Which seems a bit expensive. On the other hand we seem > to do some of that already anyway to detect unused offset ranges, so maybe > we can piggyback on that. Lets continue the offtopic part here: https://lists.fedorahosted.org/pipermail/elfutils-devel/2013-January/002881.html
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
The original script that showed the error now works with kernel 3.12.5-302.fc20.x86_64 gcc-4.8.2-7.fc20.x86_64 and systemtap-2.4-1.fc20.x86_64 Also the example from the upstream gcc bug now works with gcc-4.8.2-7.fc20.x86_64 and gdb-7.6.50.20130731-16.fc20.x86_64 Reading symbols from /tmp/a.out...done. (gdb) break foo Breakpoint 1 at 0x400690: file foo2.c, line 10. (gdb) run Starting program: /tmp/a.out Breakpoint 1, foo (a=7, b=4) at foo2.c:10 10 { Note that the upstream bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793 isn't closed yet, but still in state NEW. But that is something for upstream I guess. For Fedora this seems resolved.