* ARM ABI calling conventions
@ 2011-12-02 16:15 Mark Wielaard
2011-12-02 22:03 ` Wade Farnsworth
0 siblings, 1 reply; 3+ messages in thread
From: Mark Wielaard @ 2011-12-02 16:15 UTC (permalink / raw)
To: systemtap; +Cc: f-turgis, wade_farnsworth
Hi,
I need some help with ARM calling conventions. While cleaning up some
arm support code (I am now able to get nice backtraces across
modules/kernel boundaries using the dwarf unwinder, whoho!), I noticed
the following failures:
Running /root/systemtap/testsuite/systemtap.context/context.exp ...
FAIL: int64 function arguments -- numeric
FAIL: int64 function arguments -- numeric --kelf --ignore-dwarf
Which is now http://sourceware.org/bugzilla/show_bug.cgi?id=13466
The problem is that I don't fully understand which ABI calling
conventions are in used on the various ARM distros. Nor do I understand
how to detect which one is being used. Can the ABI calling conventions
be different between kernel and user space?
Fedora15 ARM HardFP port [*] uses EABI (though it isn't officially
called EABI anymore). That is what I am using on a little trimslice now.
But apparently older Fedora ports also used EABI (at least for the
integral argument passing, floating point argument passing is a
different story).
What tapsets/arm/register.stp seems to support is the ARM OABI.
Are there still distros that use that one?
Thanks,
Mark
[*]
https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap
which uses the calling convention described in the AAPCS
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: ARM ABI calling conventions
2011-12-02 16:15 ARM ABI calling conventions Mark Wielaard
@ 2011-12-02 22:03 ` Wade Farnsworth
2011-12-02 22:15 ` Mark Wielaard
0 siblings, 1 reply; 3+ messages in thread
From: Wade Farnsworth @ 2011-12-02 22:03 UTC (permalink / raw)
To: Mark Wielaard; +Cc: systemtap, f-turgis
Mark Wielaard wrote:
> Hi,
>
> I need some help with ARM calling conventions. While cleaning up some
> arm support code (I am now able to get nice backtraces across
> modules/kernel boundaries using the dwarf unwinder, whoho!), I noticed
> the following failures:
>
> Running /root/systemtap/testsuite/systemtap.context/context.exp ...
> FAIL: int64 function arguments -- numeric
> FAIL: int64 function arguments -- numeric --kelf --ignore-dwarf
>
> Which is now http://sourceware.org/bugzilla/show_bug.cgi?id=13466
>
> The problem is that I don't fully understand which ABI calling
> conventions are in used on the various ARM distros. Nor do I understand
> how to detect which one is being used. Can the ABI calling conventions
> be different between kernel and user space?
Yes, in theory the ABI calling conventions can differ between kernel and
user space as well as between individual user space binaries.
There are a few ways to detect the ABI option used in a particular
binary. See http://wiki.debian.org/ArmEabiPort .
>
> Fedora15 ARM HardFP port [*] uses EABI (though it isn't officially
> called EABI anymore). That is what I am using on a little trimslice now.
> But apparently older Fedora ports also used EABI (at least for the
> integral argument passing, floating point argument passing is a
> different story).
>
> What tapsets/arm/register.stp seems to support is the ARM OABI.
> Are there still distros that use that one?
>
I expect most distributions have switched to EABI by now, though it
wouldn't surprise me if there was some legacy code running somewhere
that uses OABI.
Would it be possible to support both ABIs, parsing the ELF header to
obtain the flag and then take the appropriate action?
-Wade
> Thanks,
>
> Mark
>
> [*]
> https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap
> which uses the calling convention described in the AAPCS
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: ARM ABI calling conventions
2011-12-02 22:03 ` Wade Farnsworth
@ 2011-12-02 22:15 ` Mark Wielaard
0 siblings, 0 replies; 3+ messages in thread
From: Mark Wielaard @ 2011-12-02 22:15 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: systemtap, f-turgis
On Fri, Dec 02, 2011 at 12:35:43PM -0700, Wade Farnsworth wrote:
> Yes, in theory the ABI calling conventions can differ between kernel
> and user space as well as between individual user space binaries.
> [...]
> I expect most distributions have switched to EABI by now, though it
> wouldn't surprise me if there was some legacy code running somewhere
> that uses OABI.
>
> Would it be possible to support both ABIs, parsing the ELF header to
> obtain the flag and then take the appropriate action?
I guess it would be possible. But I expect nobody uses OABI anymore
for real. Or at least not for those systems that also want to support
systemtap on ARM. Let me make my request more precise:
a) Is there anybody out there using systemtap on ARM using OABI?
b) If so, would you be willing to help out making sure systemtap
supports both OABI and EABI?
Note that this is only for things like direct register.stp argument
fetching. For dwarf based accesses things should be fine. It is also
just for integral types, since systemtap doesn't support floating
point atm. So different hard/soft float variants of the base EABI
are not something we need to deal with.
I don't mind supporting more than just base EABI, but it would be nice
to hear of anybody actually using something else these days. Especially
since I will be unable to test it myself.
Thanks,
Mark
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-12-02 22:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-02 16:15 ARM ABI calling conventions Mark Wielaard
2011-12-02 22:03 ` Wade Farnsworth
2011-12-02 22:15 ` Mark Wielaard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).