This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [BUG] syscall.unlink no longer works after upgrading kernel to 3.7.3
- From: Josh Stone <jistone at redhat dot com>
- To: Zheng Da <zhengda1936 at gmail dot com>
- Cc: Mark Wielaard <mjw at redhat dot com>, agentzh <agentzh at gmail dot com>, "systemtap at sourceware dot org" <systemtap at sourceware dot org>
- Date: Tue, 28 May 2013 17:19:17 -0700
- Subject: Re: [BUG] syscall.unlink no longer works after upgrading kernel to 3.7.3
- References: <CAB4Tn6PdW3GOa09z_tfjQs=F+7XLOqMr5+c5GourX5e0v8FMeQ at mail dot gmail dot com> <1360054656 dot 3837 dot 13 dot camel at bordewijk dot wildebeest dot org> <51114188 dot 60400 at redhat dot com> <CAFLer83DQhCQg7Y3NKR0EUYePzp+fETDTeYEthUXKarAySM0_g at mail dot gmail dot com> <20130528191449 dot GA31042 at toonder dot wildebeest dot org> <CAFLer81NE1bocCbufPTtLLZ-pZz2kVA5r3rKoCgjmc_6w+fwng at mail dot gmail dot com> <51A511FD dot 8010006 at redhat dot com> <20130528203223 dot GA768 at toonder dot wildebeest dot org> <CAFLer80-zMFK9-qqGFdsiacrYPmzD=-qxdMO_a+TP71XbpGxXA at mail dot gmail dot com> <51A534E8 dot 8000209 at redhat dot com> <CAFLer83AdR0GXa9AtEjq8gBpy1919Br0VDuaknOtZLa+S39EHA at mail dot gmail dot com>
On 05/28/2013 04:52 PM, Zheng Da wrote:
>>> [43d72e9] subprogram
>>> external (flag) Yes
>>> name (strp) "scsi_device_unbusy"
>>> decl_file (data1) 1
>>> decl_line (data2) 318
>>> prototyped (flag) Yes
>>> low_pc (addr) 0xffffffff81480e80
>>> high_pc (addr) 0xffffffff81480f44
>>> frame_base (data4) location list [e061d3]
>>> sibling (ref4) [43d7492]
>>> [43d730b] formal_parameter
>>> name (strp) "sdev"
>>> decl_file (data1) 1
>>> decl_line (data2) 318
>>> type (ref4) [43d22ff]
>>> location (data4) location list [e06233]
...
> I think I can also see the 5-byte difference here.
>
> [e061d3] 0xffffffff81480e80..0xffffffff81480e86 [ 0] breg7 8
> 0xffffffff81480e86..0xffffffff81480e89 [ 0] breg7 16
> 0xffffffff81480e89..0xffffffff81480f43 [ 0] breg6 16
> 0xffffffff81480f43..0xffffffff81480f44 [ 0] breg7 8
> [e06233] 0xffffffff81480e85..0xffffffff81480eae [ 0] reg5
> 0xffffffff81480edf..0xffffffff81480f36 [ 0] reg3
Right, so your function starts at e80, while sdev starts at e85.
> Output of objdump -d:
> ffffffff81480e80 <scsi_device_unbusy>:
> ffffffff81480e80: e8 7b 6c 22 00 callq
> ffffffff816a7b00 <__fentry__>
> ffffffff81480e85: 55 push %rbp
> ffffffff81480e86: 48 89 e5 mov %rsp,%rbp
> ffffffff81480e89: 48 83 ec 20 sub $0x20,%rsp
And indeed it lines up with the fentry call.
> I added lines in the source code of systemtap to print msg when
> dwflpp::pr15123_retry_addr returns 0.
> The problem is that the producer string returned by
> dwarf_formstring(&cudie_producer) is "GNU C 4.6.3". There isn't
> "-mfentry". I guess that is what you mean.
Yes.
> Do you want me to use -grecord-gcc-switches to rebuilt the kernel?
Yes, it appears this is needed. Or if you're building your own
SystemTap, you could just patch out the lines which look for mfentry.
The heuristic is erring on the side of caution, so we don't produce
invalid data. In any case, gcc 4.8 has fixed this issue directly.
For the record, I figured out that Fedora actually has
-grecord-gcc-switches by default for the whole distro in gcc.spec, with
this:
> sed -i '/dwarf_record_gcc_switches/s/Init(0)/Init(1)/' gcc/common.opt