[AARCH64] : Pointer mangling support for Aarch64

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

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

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,

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,

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.