[AARCH64] : Pointer mangling support for Aarch64

Message ID CAJK_mQ2isVSQgbARrRT6KYGODUyCgAavnD-TTYVYK7_bUjb6LQ@mail.gmail.com
State New
Headers show

Commit Message

Venkataramanan Kumar Jan. 7, 2014, 11:05 a.m.
Hi,

The mangling patch is already up streamed. So I will include this
addition as a separate patch.

I looked at x86 and powerpc ports. So for Aarch64
longjmp/longjmp_target probe expects
   *  first argument 8@address of jmpbuf in x0.
   *  second argument -4@return val in x1.
   *  third argument 8@ address of target in LR/X30.

The patch below does that.

(--snip--)
(--snip--)

Please let me know if this is fine,  I will start doing the testing.

regards,
Venkat.

On 6 January 2014 23:40, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> ">" == Venkataramanan Kumar <venkataramanan.kumar@linaro.org> writes:
>
>>> This patch adds pointer mangling support for Aarch64.
>
> IIRC the Aarch64 longjmp code doesn't have the sdt.h probes in place.
> If you add pointer mangling without also adding the sdt.h probes, then
> gdb's longjmp support will break.  You should be able to see this easily
> in the gdb test suite.
>
> Adding the probes is quite easy to do, so I encourage you to add that
> to the patch.
>
> thanks,
> Tom

Comments

Venkataramanan Kumar Jan. 8, 2014, 10:32 a.m. | #1
Hi Marcus,

On 7 January 2014 17:47, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote:
> On 7 January 2014 11:05, Venkataramanan Kumar
> <venkataramanan.kumar@linaro.org> wrote:
>
>> I looked at x86 and powerpc ports. So for Aarch64
>> longjmp/longjmp_target probe expects
>>    *  first argument 8@address of jmpbuf in x0.
>>    *  second argument -4@return val in x1.
>>    *  third argument 8@ address of target in LR/X30.
>
> Hi, I'm not familiar with the inner workings of STAP probes, can you
> explain what the arguments of longjmp_target should be at a semantic
> level rather than the proposed location to get the values from?

I checked below link and found the argument format.
https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation

(Snip)
For compiler-generated code, each argument will be of the form N@OP.
For hand-written assembly, or for inline assembly in C or C++, the
initial N@ may be missing.
If N is present, it describes the size of the argument. It will be one of:

1  8 bits unsigned
-1 8 bits signed
2 16 bits unsigned
-2 16 bits signed
4 32 bits unsigned
-4 32 bits signed
8 64 bits unsigned
-8 64 bits signed
(Snip)

Also looking at x86 and powerpc ports.
They pass argument 1 - the address of jump buffer
                argument 2 - return value of __longjmp
                argument 3 - PC address or the jump target

For Aarch64, the longjmp/longjmp_target probe passed as below.
   *  first argument -  8@address of jmpbuf in x0.
   *  second argument-  -4@return val in x1.
   *  third argument-  8@ PC address or jump target target in LR/X30.

is that fine?

>
> Do we need probes in setjmp aswell?

Ok, I will add that as well.
I have not yet tested, the patch by enabling --enable-systemtap as it
needs std.h. This is missing in my cross build system.

>
> Cheers
> /Marcus
Will Newton Jan. 10, 2014, 9:54 a.m. | #2
On 7 January 2014 18:10, Tom Tromey <tromey@redhat.com> wrote:

Hi Tom,

> Marcus> Hi, I'm not familiar with the inner workings of STAP probes, can you
> Marcus> explain what the arguments of longjmp_target should be at a semantic
> Marcus> level rather than the proposed location to get the values from?
>
> I was going to say manual/probes.texi but I see the longjmp probes
> aren't documented.
>
> Currently gdb only uses the third argument, which is the target PC.
>
> Marcus> Do we need probes in setjmp aswell?
>
> I think it's nice for users if the probes are the same across ports.
>
> That said, gdb itself only uses the longjmp and rtld probes from glibc.
> gdb users (or SystemTap users) can refer to the other probes though.

Do you know if it is documented anywhere what the difference is
between the longjmp and longjmp_target probes?

It looks like on i386 the registers are restored in between
longjmp/longjmp_target but on powerpc half the registers seem to have
been restored by the time the longjmp probe is executed. AFAICT gdb
does not use the longjmp_target probe either...

Thanks,
Will Newton Jan. 20, 2014, 9 a.m. | #3
On 7 January 2014 18:10, Tom Tromey <tromey@redhat.com> wrote:

Hi Tom,

> Marcus> Hi, I'm not familiar with the inner workings of STAP probes, can you
> Marcus> explain what the arguments of longjmp_target should be at a semantic
> Marcus> level rather than the proposed location to get the values from?
>
> I was going to say manual/probes.texi but I see the longjmp probes
> aren't documented.
>
> Currently gdb only uses the third argument, which is the target PC.
>
> Marcus> Do we need probes in setjmp aswell?
>
> I think it's nice for users if the probes are the same across ports.
>
> That said, gdb itself only uses the longjmp and rtld probes from glibc.
> gdb users (or SystemTap users) can refer to the other probes though.

Can you confirm that gdb does not use the longjmp_target probe? It
doesn't appear to use it as far as I can tell. Are you aware of what
consumers there are for this probe point?

Thanks,
Will Newton Jan. 20, 2014, 5:02 p.m. | #4
On 20 January 2014 16:44, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Will" == Will Newton <will.newton@linaro.org> writes:
>
> Will> Can you confirm that gdb does not use the longjmp_target probe? It
> Will> doesn't appear to use it as far as I can tell. Are you aware of what
> Will> consumers there are for this probe point?
>
> Yeah, gdb uses the "longjmp" probe, not "longjmp_target".
> I don't know what uses the latter; though it's worth noting that all
> probes are available to gdb and systemtap users, so I wouldn't
> necessarily know whether someone is using it.

It's not clear to me the difference between the two - they take the
same arguments as far as I can tell (longjmp arguments 1 and 2, and
the target PC) but longjmp_target occurs at some later point which
seems implementation dependant. For that reason I would propose new
ports (or ports lacking these probes entirely such as ARM) not
implement longjmp_target unless there is a compelling reason to do so.

Patch hide | download patch | download mbox

--- a/ports/sysdeps/aarch64/__longjmp.S
+++ b/ports/sysdeps/aarch64/__longjmp.S
@@ -18,6 +18,7 @@ 

 #include <sysdep.h>
 #include <jmpbuf-offsets.h>
+#include <stap-probe.h>

 /* __longjmp(jmpbuf, val) */

@@ -56,6 +57,7 @@  ENTRY (__longjmp)
 #else
        ldp     x29, x30, [x0, #JB_X29<<3]
 #endif
+       LIBC_PROBE (longjmp, 3, 8@x0, -4@x1, 8@x30)
        ldp      d8,  d9, [x0, #JB_D8<<3]
        ldp     d10, d11, [x0, #JB_D10<<3]
        ldp     d12, d13, [x0, #JB_D12<<3]
@@ -97,6 +99,7 @@  ENTRY (__longjmp)
 #else
        ldr     x5, [x0, #JB_SP<<3]
 #endif
+       LIBC_PROBE (longjmp_target, 3, 8@x0, -4@x1, 8@x30)
        mov     sp, x5
        cmp     x1, #0
        mov     x0, #1