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

["dsmith at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=18649

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsmith at redhat dot com

--- Comment #6 from David Smith <dsmith at redhat dot com> ---
(In reply to Martin Cermak from comment #3)
> Maybe it'd be useful to have an option to foce stap not to use debuginfo
> even if it's available. It'd be easier to use and less invasive than strip.
> I've seen more contraindications between present debuginfo and dwarfless
> probes today, e.g when testing longlong_arg() in 32-on-64 environment on
> x86_64. I see e.g. -P in the man page, but not resp. opposite switch. Dunno.
> Just saying.
> 
> This is just a sidenote, since it has nothing to do with actual fix for this
> bug.

There sort of is an option to ignore all debuginfo, by setting the
SYSTEMTAP_DEBUGINFO environment variable to the empty string. This is what the
nd_syscall.exp test case does, to make sure we're using dwarfless accesses for
everything. Here's the section from the test case:

    # Override SYSTEMTAP_DEBUGINFO_PATH to ensure no debuginfo could be used    
    set env(SYSTEMTAP_DEBUGINFO_PATH) ""                                        

See stappaths.7 for more info on SYSTEMTAP_DEBUGINFO_PATH if you are
interested.

I made this change to nd_syscall.exp after running into copy-and-paste errors
when adding probes to the nd_syscall tapsets - I'd accidentally leave a '$foo'
reference in the nd_syscall probe.

I know this works to ignore kernel debuginfo, I haven't tested to make sure it
works to ignore user program debuginfo.

-- 
You are receiving this mail because:
You are the assignee for the bug.