This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]