This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug tapsets/18649] int_arg() misbehaves on x86[_64] for 32-bit uprobe in binary having debuginfo
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Thu, 09 Jul 2015 15:49:57 +0000
- Subject: [Bug tapsets/18649] int_arg() misbehaves on x86[_64] for 32-bit uprobe in binary having debuginfo
- Auto-submitted: auto-generated
- References: <bug-18649-6586 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=18649
Josh Stone <jistone at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jistone at redhat dot com
--- Comment #2 from Josh Stone <jistone at redhat dot com> ---
(In reply to Martin Cermak from comment #0)
> 7.2 S x86_64 # gcc -m32 test.c
> 7.2 S x86_64 # stap -e 'probe process("a.out").function("testfc")
> {printf("%x\n", int_arg(1))}' -c ./a.out
> 7fff
> 7.2 S x86_64 # gcc -g -m32 test.c
> 7.2 S x86_64 # stap -e 'probe process("a.out").function("testfc")
> {printf("%x\n", int_arg(1))}' -c ./a.out
> 804840a
> 7.2 S x86_64 #
My guess is that debuginfo is allowing our prologue analysis, which means the
probe will actually be placed a few instructions in. Since the arguments are
on the stack, and the prologue will have manipulated the stack, we're no longer
looking at the right place for calling conventions. This might fail on x86_64
too for arguments >= 7.
I don't have a suggested fix off hand. A script writer can get around this by
preferring the debuginfo access anyway, like @choose_defined($arg, int_arg(1)).
--
You are receiving this mail because:
You are the assignee for the bug.