This is the mail archive of the
mailing list for the systemtap project.
[Bug tapsets/18597] long_arg() doesn't correctly handle negative values in 32-on-64 environment
- From: "dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Tue, 30 Jun 2015 17:36:50 +0000
- Subject: [Bug tapsets/18597] long_arg() doesn't correctly handle negative values in 32-on-64 environment
- Auto-submitted: auto-generated
- References: <bug-18597-6586 at http dot sourceware dot org/bugzilla/>
--- Comment #8 from David Smith <dsmith at redhat dot com> ---
(In reply to Josh Stone from comment #7)
> (In reply to David Smith from comment #5)
> > What if we decided that if you call longlong_arg() on a 64-bit OS on a
> > 32-bit process you really *want* a 64-bit value from 1 register? In some
> > ways this makes sense and it matches our old behavior. My theory here is
> > that you know what you are doing and if you call longlong_arg() on a 32-bit
> > process you must be in the true 64-bit function at this point.
> That assumes you're only using this in the kernel. For a uprobe,
> longlong_arg() still needs to follow the 2-register ABI, no? That's when
> the probing_32bit_app() branch should be active.
> So yes, longlong_arg() in 64-bit kernel context should use 1 register,
> regardless of the task, but a 32-bit user context still needs to use 2
We can certainly add that code back, but do we know of anyone using the
stp_arg()-based dwarfless parameters functions from uprobes? Do we test that?
You are receiving this mail because:
You are the assignee for the bug.