Re: [Fwd: Re: Regarding systemtap support for AArch64]

[Petr Machata <pmachata at redhat dot com>]

Mark Wielaard <mjw@redhat.com> writes:

> According to the call abi the simple integer value should be in
> register "x0".  It looks in the generated c code for the module that
> it is trying to access the return value with:
>
>     { int64_t value = fetch_register (0); STAP_RETVALUE = value; }

Is this using ebl_return_value_location?  That should be on the branch,
and unless I'm interpreting things wrong, it's doing the right thing:

$ ./tests/funcretval -e ~/tmp/aarch64-ble
() fun_char: return value location: {0x50, 0}
() fun_short: return value location: {0x50, 0}
() fun_int: return value location: {0x50, 0}
() fun_ptr: return value location: {0x50, 0}
() fun_iptr: return value location: {0x50, 0}
() fun_long: return value location: {0x50, 0}
() fun_int128: return value location: {0x50, 0} {0x93, 0x8} {0x51, 0} {0x93, 0x8}
[...]

I don't think there are any real tests for this in elfutils--such that
would really check that yes, the values that we expect are in the
registers that ebl_return_value_location claims.

An idea that I had was to start a binary that calls a function and
crashes (br 0?), and then inspect the coredump to see if the values are
in the registers that elfutils expect.  But that seems cumbersome.  I'm
reluctant to use ptrace, but that would obviously work as well.

> As a sanity check I ran a "make -s check" on the locally built aarch64
> elfutils to see if there were any issues with it.

Yes, I know of the failures.  The port isn't finished yet.  I had to
switch gears for some other work.  I'm probably missing a bunch of hooks
that need implementing, I'm working through them one at a time.

Thanks,
PM