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: Tue, 05 Nov 2013 11:08:56 -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> <5277FBF2 dot 2080108 at redhat dot com> <m2wqknmumc dot fsf at redhat dot com>
On 11/04/2013 09:48 PM, Petr Machata wrote:
> William Cohen <wcohen@redhat.com> writes:
>
>> 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"
>
> That 0x3F in x8 might be __NR_read, that might be from the syscall that
> got us here. So possibly makes sense. 0x112 is __NR_syscalls, I don't
> see how that ended up there. Maybe from a conditional? 0x2004 might
> certainly be a length, though it's an odd one. The two kernel-space
> parameters have similar values, and the one user-space is quite
> different--again, makes sense.
>
> So why doesn't the return value appear in x0 I don't understand. Is the
> 0x15 in orig_X0 the right return value?
>
> Thanks,
> PM
>
Hi Petr,
These examples systemtap might not be the best. It is just printing information for the first vfs.read or vfs.read.return encountered, so the precise values are not known for the run of these examples. These are more sanity checks. Do the values here make sense? The $return value doesn't; it should be either a positive number or some small negative number. The number printed for $return matches with what is in x0 of pt_reg, so getting a value from what appears to be the right place. However, that value in x0 looks questionable.
I wonder if there might be some issue with the patches implementing the arm64 kprobes support and that the registers are not be saved properly.
-Will