This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tapsets/18649] int_arg() misbehaves on x86[_64] for 32-bit uprobe in binary having debuginfo


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]