This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [Fwd: Re: Regarding systemtap support for AArch64]
- From: William Cohen <wcohen at redhat dot com>
- To: Petr Machata <pmachata at redhat dot com>
- Cc: Mark Wielaard <mjw at redhat dot com>, Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, systemtap at sourceware dot org, Deepak Saxena <dsaxena at linaro dot org>, Krishna Dani <krishna dot mohan at linaro dot org>, Jakub Pavelek <jakub dot pavelek at linaro dot org>, Mark Salter <msalter at redhat dot com>
- Date: Mon, 04 Nov 2013 14:56:34 -0500
- Subject: Re: [Fwd: Re: Regarding systemtap support for AArch64]
- Authentication-results: sourceware.org; auth=none
- References: <1383340682 dot 3850 dot 864 dot camel at bordewijk dot wildebeest dot org> <m2habsnq4w dot fsf at redhat dot com>
On 11/04/2013 10:27 AM, Petr Machata wrote:
> 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
>
Hi Petr,
Thanks for working on the elfutils aarch64 support.
I implemented the print_regs() function for systemtap to print out the various fields in pt_regs. I have the print_regs() ansl printing out the orig_x0 and syscallno fields also. The x0 field's value looks questionable as seen below in the short one- line systemtap scripts on the aarch64.
$ sudo ~/systemtap_write/install/bin/stap -k -e 'probe vfs.read.return {printf("$return = 0x%x\n", $return);print_regs(); exit()}'
[sudo] password for wcohen:
$return = 0xffffffc04abe5e00
CPU: 0
x0 : FFFFFFC04ABE5E00 0000007FCC574070 0000000000002004 FFFFFFC077CFBEB0
x4 : 0000000000000000 0000000000000002 0000000000000000 0000000000000005
x8 : 000000000000003F 0000000000000028 0000000000401277 0000007FCC571E70
x12: 0000000000000000 0000000000000001 0000007FCC5763B0 0000000000000004
x16: FFFFFFC0001868E0 0000007FA3F26A50 0000007FCC571B90 FFFFFFC04ABE5E00
x20: 0000007FCC574070 0000000000000001 0000007FA3F26AA8 0000000080000000
x24: 0000000000000015 0000000000000112 000000000000003F FFFFFFC000835000
x28: FFFFFFC077CF8000 FFFFFFC077CFBE80 FFFFFFC000186924
sp [ffffffc077cfbe30] pc [ffffffc000186134]
pstate [0000000060000145]
orig_x0 [0000000000000015]
syscallno [0000000000000112]
Keeping temporary directory "/tmp/stap1OWdNi"
$ sudo ~/systemtap_write/install/bin/stap -k -e 'probe vfs.read {printf("$$parms = %sn", $$parms);print_regs(); exit()}'
[sudo] password for wcohen:
$$parms = file=0xffffffc04ab83e00 buf=0x7fdaad4290 count=0x2004 pos=0xffffffc043847eb0n CPU: 0
x0 : FFFFFFC04AB83E00 0000007FDAAD4290 0000000000002004 FFFFFFC043847EB0
x4 : 0000000000000000 0000000000000002 0000000000000000 0000000000000005
x8 : 000000000000003F 0000000000000028 0000000000401277 0000007FDAAD2090
x12: 0000000000000000 0000000000000001 0000007FDAAD65D0 0000000000000004
x16: FFFFFFC0001868E0 0000007F7F6E0A50 0000007FDAAD1DB0 FFFFFFC04AB83E00
x20: 0000007FDAAD4290 0000000000000001 0000007F7F6E0AA8 0000000080000000
x24: 0000000000000015 0000000000000112 000000000000003F FFFFFFC000835000
x28: FFFFFFC043844000 FFFFFFC043847E80 FFFFFFC000186924
sp [ffffffc043847e80] pc [ffffffc000186130]
pstate [0000000060000145]
orig_x0 [0000007fdaad4120]
syscallno [ffffffc000082fec]
Keeping temporary directory "/tmp/stapQI9d6o"
-Will