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: "dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Mon, 13 Jul 2015 14:38:27 +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
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.