Is there single step debugging support being added to aarch64-linux?

Is there single step debugging support being added to aarch64-linux?

[Prafull Suryawanshi]

I am trying it on 64 bit armv8 system but not able to doit.
Found issue in gdb source code and absence of this function in
aarch64-linux-tdep.c file. Anyone knows if support getting added or
not?

Thanks,
Prafull

Re: Is there single step debugging support being added to aarch64-linux?

[Andreas Schwab]

Prafull Suryawanshi <prafull.net@gmail.com> writes:

> I am trying it on 64 bit armv8 system but not able to doit.
> Found issue in gdb source code and absence of this function in
> aarch64-linux-tdep.c file. Anyone knows if support getting added or
> not?

The stepi command is working fine on aarch64.  What do you get if you
try it?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Is there single step debugging support being added to aarch64-linux?

[Prafull Suryawanshi]

I am using kgdb and trying to do single step (software single step).
I see that infrun loops. (I enabled remote_debug option and compiled
gdb 7.7 as 7.9 has issue with connection)

infrun: clear_proceed_status_thread (Thread 3462)
infrun: clear_proceed_status_thread (Thread 3444)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current
thread [Thread 3462] at 0xffffffc00021014c
Sending packet: $Hcd86#7d...Ack
Packet received: OK
Sending packet: $s#73...Ack
infrun: wait_for_inferior ()
Packet received: T05thread:0d86;
infrun: target_wait (-1, status) =
infrun:   42000 [Thread 3462],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
Sending packet: $g#67...Ack
Packet received:
c045b049c0ffffff01000000000000004c012100c0fffffff912a660c0ffffff28849f36c0ffffff000000000000000030334901c0ffffff00000000000000003f000000000000000000000000000000009000000000000001000000000000000100000000000000c012800820000000c012800820000000c0e0000000000000d8981a00c0ffffffdc1c650820000000c012800820000000c045b049c0ffffff010000000000000001000000000000000000000000000000c8be0d35c0ffffff80e91b58c0ffffff0010000000000000f845b049c0ffffff00a0c5082000000000800d35c0ffffffc0bd0d35c0fffffffcea1c00c0fffffff0bb0d35c0ffffff50012100c0ffffff450100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
infrun: stop_pc = 0xffffffc000210150
Sending packet: $mffffffc000210150,4#4d...Ack
Packet received: fd030091
Sending packet: $mffffffc00021014c,4#7f...Ack
Packet received: fd7ba3a9
Sending packet: $mffffffc000210150,4#4d...Ack
Packet received: fd030091
infrun: stepping inside range [0xffffffc00021014c-0xffffffc000210170]
Sending packet: $Z0,ffffffc00021014c,4#c8...Ack
Packet received: OK
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current
thread [Thread 3462] at 0xffffffc000210150
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $s#73...Ack
infrun: prepare_to_wait

Then I build the gdb using arch_dump enable option
gdbarch_dump: gdbarch_software_single_step_p() = 0

I see that in gdb code, function aarch64_linux_software_single_step not present.

I guess above loop expected if aarch64_linux_software_single_step absent, right?

Thanks,
Prafull

On Mon, Jun 15, 2015 at 4:08 PM, Andreas Schwab <schwab@suse.de> wrote:
> Prafull Suryawanshi <prafull.net@gmail.com> writes:
>
>> I am trying it on 64 bit armv8 system but not able to doit.
>> Found issue in gdb source code and absence of this function in
>> aarch64-linux-tdep.c file. Anyone knows if support getting added or
>> not?
>
> The stepi command is working fine on aarch64.  What do you get if you
> try it?
>
> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."

Re: Is there single step debugging support being added to aarch64-linux?

[Andreas Schwab]

Prafull Suryawanshi <prafull.net@gmail.com> writes:

> I am using kgdb

So this isn't about gdb, it is about kgdb.  Not on-topic here.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Is there single step debugging support being added to aarch64-linux?

[Prafull Suryawanshi]

I am using gdb to talk to kgdb, so is not issue with gdb?
gdb is not able to set software single step like it do for arm.
There is implementation for gdbarch_software_single_step_p in arm gdb
but not in aarch64 gdb.

In fact, I had small implementation to get next_pc at fixed offset
(+4) and it starts working. (implementing full version)

Let me know.

Thanks,
Prafull


On Mon, Jun 15, 2015 at 4:27 PM, Prafull Suryawanshi
<prafull.net@gmail.com> wrote:
> I am using kgdb and trying to do single step (software single step).
> I see that infrun loops. (I enabled remote_debug option and compiled
> gdb 7.7 as 7.9 has issue with connection)
>
> infrun: clear_proceed_status_thread (Thread 3462)
> infrun: clear_proceed_status_thread (Thread 3444)
> infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
> infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current
> thread [Thread 3462] at 0xffffffc00021014c
> Sending packet: $Hcd86#7d...Ack
> Packet received: OK
> Sending packet: $s#73...Ack
> infrun: wait_for_inferior ()
> Packet received: T05thread:0d86;
> infrun: target_wait (-1, status) =
> infrun:   42000 [Thread 3462],
> infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
> infrun: infwait_normal_state
> infrun: TARGET_WAITKIND_STOPPED
> Sending packet: $g#67...Ack
> Packet received:
> c045b049c0ffffff01000000000000004c012100c0fffffff912a660c0ffffff28849f36c0ffffff000000000000000030334901c0ffffff00000000000000003f000000000000000000000000000000009000000000000001000000000000000100000000000000c012800820000000c012800820000000c0e0000000000000d8981a00c0ffffffdc1c650820000000c012800820000000c045b049c0ffffff010000000000000001000000000000000000000000000000c8be0d35c0ffffff80e91b58c0ffffff0010000000000000f845b049c0ffffff00a0c5082000000000800d35c0ffffffc0bd0d35c0fffffffcea1c00c0fffffff0bb0d35c0ffffff50012100c0ffffff450100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> infrun: stop_pc = 0xffffffc000210150
> Sending packet: $mffffffc000210150,4#4d...Ack
> Packet received: fd030091
> Sending packet: $mffffffc00021014c,4#7f...Ack
> Packet received: fd7ba3a9
> Sending packet: $mffffffc000210150,4#4d...Ack
> Packet received: fd030091
> infrun: stepping inside range [0xffffffc00021014c-0xffffffc000210170]
> Sending packet: $Z0,ffffffc00021014c,4#c8...Ack
> Packet received: OK
> infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current
> thread [Thread 3462] at 0xffffffc000210150
> Sending packet: $Hc0#db...Ack
> Packet received: OK
> Sending packet: $s#73...Ack
> infrun: prepare_to_wait
>
> Then I build the gdb using arch_dump enable option
> gdbarch_dump: gdbarch_software_single_step_p() = 0
>
> I see that in gdb code, function aarch64_linux_software_single_step not present.
>
> I guess above loop expected if aarch64_linux_software_single_step absent, right?
>
> Thanks,
> Prafull
>
> On Mon, Jun 15, 2015 at 4:08 PM, Andreas Schwab <schwab@suse.de> wrote:
>> Prafull Suryawanshi <prafull.net@gmail.com> writes:
>>
>>> I am trying it on 64 bit armv8 system but not able to doit.
>>> Found issue in gdb source code and absence of this function in
>>> aarch64-linux-tdep.c file. Anyone knows if support getting added or
>>> not?
>>
>> The stepi command is working fine on aarch64.  What do you get if you
>> try it?
>>
>> Andreas.
>>
>> --
>> Andreas Schwab, SUSE Labs, schwab@suse.de
>> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
>> "And now for something completely different."

Re: Is there single step debugging support being added to aarch64-linux?

[pinskia]

> On Jun 15, 2015, at 4:07 AM, Prafull Suryawanshi <prafull.net@gmail.com> wrote:
> 
> I am using gdb to talk to kgdb, so is not issue with gdb?
> gdb is not able to set software single step like it do for arm.
> There is implementation for gdbarch_software_single_step_p in arm gdb
> but not in aarch64 gdb.
> 
> In fact, I had small implementation to get next_pc at fixed offset
> (+4) and it starts working. (implementing full version)


Why can't you use the hardware single stepper for kgdb?

Thanks,
Andrew

> 
> Let me know.
> 
> Thanks,
> Prafull
> 
> 
> On Mon, Jun 15, 2015 at 4:27 PM, Prafull Suryawanshi
> <prafull.net@gmail.com> wrote:
>> I am using kgdb and trying to do single step (software single step).
>> I see that infrun loops. (I enabled remote_debug option and compiled
>> gdb 7.7 as 7.9 has issue with connection)
>> 
>> infrun: clear_proceed_status_thread (Thread 3462)
>> infrun: clear_proceed_status_thread (Thread 3444)
>> infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
>> infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current
>> thread [Thread 3462] at 0xffffffc00021014c
>> Sending packet: $Hcd86#7d...Ack
>> Packet received: OK
>> Sending packet: $s#73...Ack
>> infrun: wait_for_inferior ()
>> Packet received: T05thread:0d86;
>> infrun: target_wait (-1, status) =
>> infrun:   42000 [Thread 3462],
>> infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
>> infrun: infwait_normal_state
>> infrun: TARGET_WAITKIND_STOPPED
>> Sending packet: $g#67...Ack
>> Packet received:
>> c045b049c0ffffff01000000000000004c012100c0fffffff912a660c0ffffff28849f36c0ffffff000000000000000030334901c0ffffff00000000000000003f000000000000000000000000000000009000000000000001000000000000000100000000000000c012800820000000c012800820000000c0e0000000000000d8981a00c0ffffffdc1c650820000000c012800820000000c045b049c0ffffff010000000000000001000000000000000000000000000000c8be0d35c0ffffff80e91b58c0ffffff0010000000000000f845b049c0ffffff00a0c5082000000000800d35c0ffffffc0bd0d35c0fffffffcea1c00c0fffffff0bb0d35c0ffffff50012100c0ffffff450100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>> infrun: stop_pc = 0xffffffc000210150
>> Sending packet: $mffffffc000210150,4#4d...Ack
>> Packet received: fd030091
>> Sending packet: $mffffffc00021014c,4#7f...Ack
>> Packet received: fd7ba3a9
>> Sending packet: $mffffffc000210150,4#4d...Ack
>> Packet received: fd030091
>> infrun: stepping inside range [0xffffffc00021014c-0xffffffc000210170]
>> Sending packet: $Z0,ffffffc00021014c,4#c8...Ack
>> Packet received: OK
>> infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current
>> thread [Thread 3462] at 0xffffffc000210150
>> Sending packet: $Hc0#db...Ack
>> Packet received: OK
>> Sending packet: $s#73...Ack
>> infrun: prepare_to_wait
>> 
>> Then I build the gdb using arch_dump enable option
>> gdbarch_dump: gdbarch_software_single_step_p() = 0
>> 
>> I see that in gdb code, function aarch64_linux_software_single_step not present.
>> 
>> I guess above loop expected if aarch64_linux_software_single_step absent, right?
>> 
>> Thanks,
>> Prafull
>> 
>>> On Mon, Jun 15, 2015 at 4:08 PM, Andreas Schwab <schwab@suse.de> wrote:
>>> Prafull Suryawanshi <prafull.net@gmail.com> writes:
>>> 
>>>> I am trying it on 64 bit armv8 system but not able to doit.
>>>> Found issue in gdb source code and absence of this function in
>>>> aarch64-linux-tdep.c file. Anyone knows if support getting added or
>>>> not?
>>> 
>>> The stepi command is working fine on aarch64.  What do you get if you
>>> try it?
>>> 
>>> Andreas.
>>> 
>>> --
>>> Andreas Schwab, SUSE Labs, schwab@suse.de
>>> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
>>> "And now for something completely different."

Re: Is there single step debugging support being added to aarch64-linux?

[Prafull Suryawanshi]

I am not sure why hw stepper not works here (might be limitation of hw
I am using).
That is may be the infrun loops as it never gets stop signal. (the
output I earlier pasted).
Is it ok to provide patch for software single step like arm here?
(I am preparing one. It will have simulate aarch64 instruction set and
implement aarch64 version of functions of
arm_linux_software_single_step, arm_insert_single_step_breakpoint and
arm_get_next_pc.)

Thanks,
Prafull

On Mon, Jun 15, 2015 at 4:49 PM,  <pinskia@gmail.com> wrote:
>
>
>
>
>> On Jun 15, 2015, at 4:07 AM, Prafull Suryawanshi <prafull.net@gmail.com> wrote:
>>
>> I am using gdb to talk to kgdb, so is not issue with gdb?
>> gdb is not able to set software single step like it do for arm.
>> There is implementation for gdbarch_software_single_step_p in arm gdb
>> but not in aarch64 gdb.
>>
>> In fact, I had small implementation to get next_pc at fixed offset
>> (+4) and it starts working. (implementing full version)
>
>
> Why can't you use the hardware single stepper for kgdb?
>
> Thanks,
> Andrew
>
>>
>> Let me know.
>>
>> Thanks,
>> Prafull
>>
>>
>> On Mon, Jun 15, 2015 at 4:27 PM, Prafull Suryawanshi
>> <prafull.net@gmail.com> wrote:
>>> I am using kgdb and trying to do single step (software single step).
>>> I see that infrun loops. (I enabled remote_debug option and compiled
>>> gdb 7.7 as 7.9 has issue with connection)
>>>
>>> infrun: clear_proceed_status_thread (Thread 3462)
>>> infrun: clear_proceed_status_thread (Thread 3444)
>>> infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
>>> infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current
>>> thread [Thread 3462] at 0xffffffc00021014c
>>> Sending packet: $Hcd86#7d...Ack
>>> Packet received: OK
>>> Sending packet: $s#73...Ack
>>> infrun: wait_for_inferior ()
>>> Packet received: T05thread:0d86;
>>> infrun: target_wait (-1, status) =
>>> infrun:   42000 [Thread 3462],
>>> infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
>>> infrun: infwait_normal_state
>>> infrun: TARGET_WAITKIND_STOPPED
>>> Sending packet: $g#67...Ack
>>> Packet received:
>>> c045b049c0ffffff01000000000000004c012100c0fffffff912a660c0ffffff28849f36c0ffffff000000000000000030334901c0ffffff00000000000000003f000000000000000000000000000000009000000000000001000000000000000100000000000000c012800820000000c012800820000000c0e0000000000000d8981a00c0ffffffdc1c650820000000c012800820000000c045b049c0ffffff010000000000000001000000000000000000000000000000c8be0d35c0ffffff80e91b58c0ffffff0010000000000000f845b049c0ffffff00a0c5082000000000800d35c0ffffffc0bd0d35c0fffffffcea1c00c0fffffff0bb0d35c0ffffff50012100c0ffffff450100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>>> infrun: stop_pc = 0xffffffc000210150
>>> Sending packet: $mffffffc000210150,4#4d...Ack
>>> Packet received: fd030091
>>> Sending packet: $mffffffc00021014c,4#7f...Ack
>>> Packet received: fd7ba3a9
>>> Sending packet: $mffffffc000210150,4#4d...Ack
>>> Packet received: fd030091
>>> infrun: stepping inside range [0xffffffc00021014c-0xffffffc000210170]
>>> Sending packet: $Z0,ffffffc00021014c,4#c8...Ack
>>> Packet received: OK
>>> infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current
>>> thread [Thread 3462] at 0xffffffc000210150
>>> Sending packet: $Hc0#db...Ack
>>> Packet received: OK
>>> Sending packet: $s#73...Ack
>>> infrun: prepare_to_wait
>>>
>>> Then I build the gdb using arch_dump enable option
>>> gdbarch_dump: gdbarch_software_single_step_p() = 0
>>>
>>> I see that in gdb code, function aarch64_linux_software_single_step not present.
>>>
>>> I guess above loop expected if aarch64_linux_software_single_step absent, right?
>>>
>>> Thanks,
>>> Prafull
>>>
>>>> On Mon, Jun 15, 2015 at 4:08 PM, Andreas Schwab <schwab@suse.de> wrote:
>>>> Prafull Suryawanshi <prafull.net@gmail.com> writes:
>>>>
>>>>> I am trying it on 64 bit armv8 system but not able to doit.
>>>>> Found issue in gdb source code and absence of this function in
>>>>> aarch64-linux-tdep.c file. Anyone knows if support getting added or
>>>>> not?
>>>>
>>>> The stepi command is working fine on aarch64.  What do you get if you
>>>> try it?
>>>>
>>>> Andreas.
>>>>
>>>> --
>>>> Andreas Schwab, SUSE Labs, schwab@suse.de
>>>> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
>>>> "And now for something completely different."

Re: Is there single step debugging support being added to aarch64-linux?

[pinskia]

> On Jun 15, 2015, at 4:48 AM, Prafull Suryawanshi <prafull.net@gmail.com> wrote:
> 
> I am not sure why hw stepper not works here (might be limitation of hw
> I am using).
> That is may be the infrun loops as it never gets stop signal. (the
> output I earlier pasted).
> Is it ok to provide patch for software single step like arm here?
> (I am preparing one. It will have simulate aarch64 instruction set and
> implement aarch64 version of functions of
> arm_linux_software_single_step, arm_insert_single_step_breakpoint and
> arm_get_next_pc.)


We do need one but for stepping over ldxr/stxr pairs. 

Thanks,
Andrew

> 
> Thanks,
> Prafull
> 
>> On Mon, Jun 15, 2015 at 4:49 PM,  <pinskia@gmail.com> wrote:
>> 
>> 
>> 
>> 
>>> On Jun 15, 2015, at 4:07 AM, Prafull Suryawanshi <prafull.net@gmail.com> wrote:
>>> 
>>> I am using gdb to talk to kgdb, so is not issue with gdb?
>>> gdb is not able to set software single step like it do for arm.
>>> There is implementation for gdbarch_software_single_step_p in arm gdb
>>> but not in aarch64 gdb.
>>> 
>>> In fact, I had small implementation to get next_pc at fixed offset
>>> (+4) and it starts working. (implementing full version)
>> 
>> 
>> Why can't you use the hardware single stepper for kgdb?
>> 
>> Thanks,
>> Andrew
>> 
>>> 
>>> Let me know.
>>> 
>>> Thanks,
>>> Prafull
>>> 
>>> 
>>> On Mon, Jun 15, 2015 at 4:27 PM, Prafull Suryawanshi
>>> <prafull.net@gmail.com> wrote:
>>>> I am using kgdb and trying to do single step (software single step).
>>>> I see that infrun loops. (I enabled remote_debug option and compiled
>>>> gdb 7.7 as 7.9 has issue with connection)
>>>> 
>>>> infrun: clear_proceed_status_thread (Thread 3462)
>>>> infrun: clear_proceed_status_thread (Thread 3444)
>>>> infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
>>>> infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current
>>>> thread [Thread 3462] at 0xffffffc00021014c
>>>> Sending packet: $Hcd86#7d...Ack
>>>> Packet received: OK
>>>> Sending packet: $s#73...Ack
>>>> infrun: wait_for_inferior ()
>>>> Packet received: T05thread:0d86;
>>>> infrun: target_wait (-1, status) =
>>>> infrun:   42000 [Thread 3462],
>>>> infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
>>>> infrun: infwait_normal_state
>>>> infrun: TARGET_WAITKIND_STOPPED
>>>> Sending packet: $g#67...Ack
>>>> Packet received:
>>>> c045b049c0ffffff01000000000000004c012100c0fffffff912a660c0ffffff28849f36c0ffffff000000000000000030334901c0ffffff00000000000000003f000000000000000000000000000000009000000000000001000000000000000100000000000000c012800820000000c012800820000000c0e0000000000000d8981a00c0ffffffdc1c650820000000c012800820000000c045b049c0ffffff010000000000000001000000000000000000000000000000c8be0d35c0ffffff80e91b58c0ffffff0010000000000000f845b049c0ffffff00a0c5082000000000800d35c0ffffffc0bd0d35c0fffffffcea1c00c0fffffff0bb0d35c0ffffff50012100c0ffffff450100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>>>> infrun: stop_pc = 0xffffffc000210150
>>>> Sending packet: $mffffffc000210150,4#4d...Ack
>>>> Packet received: fd030091
>>>> Sending packet: $mffffffc00021014c,4#7f...Ack
>>>> Packet received: fd7ba3a9
>>>> Sending packet: $mffffffc000210150,4#4d...Ack
>>>> Packet received: fd030091
>>>> infrun: stepping inside range [0xffffffc00021014c-0xffffffc000210170]
>>>> Sending packet: $Z0,ffffffc00021014c,4#c8...Ack
>>>> Packet received: OK
>>>> infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current
>>>> thread [Thread 3462] at 0xffffffc000210150
>>>> Sending packet: $Hc0#db...Ack
>>>> Packet received: OK
>>>> Sending packet: $s#73...Ack
>>>> infrun: prepare_to_wait
>>>> 
>>>> Then I build the gdb using arch_dump enable option
>>>> gdbarch_dump: gdbarch_software_single_step_p() = 0
>>>> 
>>>> I see that in gdb code, function aarch64_linux_software_single_step not present.
>>>> 
>>>> I guess above loop expected if aarch64_linux_software_single_step absent, right?
>>>> 
>>>> Thanks,
>>>> Prafull
>>>> 
>>>>> On Mon, Jun 15, 2015 at 4:08 PM, Andreas Schwab <schwab@suse.de> wrote:
>>>>> Prafull Suryawanshi <prafull.net@gmail.com> writes:
>>>>> 
>>>>>> I am trying it on 64 bit armv8 system but not able to doit.
>>>>>> Found issue in gdb source code and absence of this function in
>>>>>> aarch64-linux-tdep.c file. Anyone knows if support getting added or
>>>>>> not?
>>>>> 
>>>>> The stepi command is working fine on aarch64.  What do you get if you
>>>>> try it?
>>>>> 
>>>>> Andreas.
>>>>> 
>>>>> --
>>>>> Andreas Schwab, SUSE Labs, schwab@suse.de
>>>>> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
>>>>> "And now for something completely different."

Re: Is there single step debugging support being added to aarch64-linux?

[Prafull Suryawanshi]

Thanks. Adding one. Will send it to gdb-patches.

-Prafull

On Mon, Jun 15, 2015 at 5:27 PM,  <pinskia@gmail.com> wrote:
>
>
>
>
>> On Jun 15, 2015, at 4:48 AM, Prafull Suryawanshi <prafull.net@gmail.com> wrote:
>>
>> I am not sure why hw stepper not works here (might be limitation of hw
>> I am using).
>> That is may be the infrun loops as it never gets stop signal. (the
>> output I earlier pasted).
>> Is it ok to provide patch for software single step like arm here?
>> (I am preparing one. It will have simulate aarch64 instruction set and
>> implement aarch64 version of functions of
>> arm_linux_software_single_step, arm_insert_single_step_breakpoint and
>> arm_get_next_pc.)
>
>
> We do need one but for stepping over ldxr/stxr pairs.
>
> Thanks,
> Andrew
>
>>
>> Thanks,
>> Prafull
>>
>>> On Mon, Jun 15, 2015 at 4:49 PM,  <pinskia@gmail.com> wrote:
>>>
>>>
>>>
>>>
>>>> On Jun 15, 2015, at 4:07 AM, Prafull Suryawanshi <prafull.net@gmail.com> wrote:
>>>>
>>>> I am using gdb to talk to kgdb, so is not issue with gdb?
>>>> gdb is not able to set software single step like it do for arm.
>>>> There is implementation for gdbarch_software_single_step_p in arm gdb
>>>> but not in aarch64 gdb.
>>>>
>>>> In fact, I had small implementation to get next_pc at fixed offset
>>>> (+4) and it starts working. (implementing full version)
>>>
>>>
>>> Why can't you use the hardware single stepper for kgdb?
>>>
>>> Thanks,
>>> Andrew
>>>
>>>>
>>>> Let me know.
>>>>
>>>> Thanks,
>>>> Prafull
>>>>
>>>>
>>>> On Mon, Jun 15, 2015 at 4:27 PM, Prafull Suryawanshi
>>>> <prafull.net@gmail.com> wrote:
>>>>> I am using kgdb and trying to do single step (software single step).
>>>>> I see that infrun loops. (I enabled remote_debug option and compiled
>>>>> gdb 7.7 as 7.9 has issue with connection)
>>>>>
>>>>> infrun: clear_proceed_status_thread (Thread 3462)
>>>>> infrun: clear_proceed_status_thread (Thread 3444)
>>>>> infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
>>>>> infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current
>>>>> thread [Thread 3462] at 0xffffffc00021014c
>>>>> Sending packet: $Hcd86#7d...Ack
>>>>> Packet received: OK
>>>>> Sending packet: $s#73...Ack
>>>>> infrun: wait_for_inferior ()
>>>>> Packet received: T05thread:0d86;
>>>>> infrun: target_wait (-1, status) =
>>>>> infrun:   42000 [Thread 3462],
>>>>> infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
>>>>> infrun: infwait_normal_state
>>>>> infrun: TARGET_WAITKIND_STOPPED
>>>>> Sending packet: $g#67...Ack
>>>>> Packet received:
>>>>> c045b049c0ffffff01000000000000004c012100c0fffffff912a660c0ffffff28849f36c0ffffff000000000000000030334901c0ffffff00000000000000003f000000000000000000000000000000009000000000000001000000000000000100000000000000c012800820000000c012800820000000c0e0000000000000d8981a00c0ffffffdc1c650820000000c012800820000000c045b049c0ffffff010000000000000001000000000000000000000000000000c8be0d35c0ffffff80e91b58c0ffffff0010000000000000f845b049c0ffffff00a0c5082000000000800d35c0ffffffc0bd0d35c0fffffffcea1c00c0fffffff0bb0d35c0ffffff50012100c0ffffff450100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>>>>> infrun: stop_pc = 0xffffffc000210150
>>>>> Sending packet: $mffffffc000210150,4#4d...Ack
>>>>> Packet received: fd030091
>>>>> Sending packet: $mffffffc00021014c,4#7f...Ack
>>>>> Packet received: fd7ba3a9
>>>>> Sending packet: $mffffffc000210150,4#4d...Ack
>>>>> Packet received: fd030091
>>>>> infrun: stepping inside range [0xffffffc00021014c-0xffffffc000210170]
>>>>> Sending packet: $Z0,ffffffc00021014c,4#c8...Ack
>>>>> Packet received: OK
>>>>> infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current
>>>>> thread [Thread 3462] at 0xffffffc000210150
>>>>> Sending packet: $Hc0#db...Ack
>>>>> Packet received: OK
>>>>> Sending packet: $s#73...Ack
>>>>> infrun: prepare_to_wait
>>>>>
>>>>> Then I build the gdb using arch_dump enable option
>>>>> gdbarch_dump: gdbarch_software_single_step_p() = 0
>>>>>
>>>>> I see that in gdb code, function aarch64_linux_software_single_step not present.
>>>>>
>>>>> I guess above loop expected if aarch64_linux_software_single_step absent, right?
>>>>>
>>>>> Thanks,
>>>>> Prafull
>>>>>
>>>>>> On Mon, Jun 15, 2015 at 4:08 PM, Andreas Schwab <schwab@suse.de> wrote:
>>>>>> Prafull Suryawanshi <prafull.net@gmail.com> writes:
>>>>>>
>>>>>>> I am trying it on 64 bit armv8 system but not able to doit.
>>>>>>> Found issue in gdb source code and absence of this function in
>>>>>>> aarch64-linux-tdep.c file. Anyone knows if support getting added or
>>>>>>> not?
>>>>>>
>>>>>> The stepi command is working fine on aarch64.  What do you get if you
>>>>>> try it?
>>>>>>
>>>>>> Andreas.
>>>>>>
>>>>>> --
>>>>>> Andreas Schwab, SUSE Labs, schwab@suse.de
>>>>>> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
>>>>>> "And now for something completely different."

Re: Is there single step debugging support being added to aarch64-linux?

[Yao Qi]

Prafull Suryawanshi <prafull.net@gmail.com> writes:

> I am not sure why hw stepper not works here (might be limitation of hw
> I am using).

You'd better to check whether hw single step doesn't work in your case.

> That is may be the infrun loops as it never gets stop signal. (the
> output I earlier pasted).
> Is it ok to provide patch for software single step like arm here?

We only implement software single step on the targets don't have
hardware single step capability, like arm.

> (I am preparing one. It will have simulate aarch64 instruction set and
> implement aarch64 version of functions of
> arm_linux_software_single_step, arm_insert_single_step_breakpoint and
> arm_get_next_pc.)

Before you start it, better to get the reason why hw single step doesn't
work on aarch64.

-- 
Yao (齐尧)

Re: Is there single step debugging support being added to aarch64-linux?

[Prafull Suryawanshi]

I debugged this one and found that when compared to gdb-arm,
gdb-aarch64 behaves little different.
Before even invoking software-single-step operations, gdb-arm invokes
Z0 packet before getting registers.
But gdb-aarch64 does not do it. It sets the Z0 after reading registers.
So in case gdb-arm, the Z0 is set to next pc value.
But for gdb-aarch64 it sets the Z0 at current pc only.

Below is logs when enabled remote_debug option.
for gdb-arm
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current
thread [Thread 2229] at 0xc01b2ddc
Sending packet: $Z0,c01b2de0,4#67...Ack


For gdb-aarch64,
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current
thread [Thread 3462] at 0xffffffc00021014c

On Mon, Jun 15, 2015 at 6:21 PM, Yao Qi <qiyaoltc@gmail.com> wrote:
> Prafull Suryawanshi <prafull.net@gmail.com> writes:
>
>> I am not sure why hw stepper not works here (might be limitation of hw
>> I am using).
>
> You'd better to check whether hw single step doesn't work in your case.
>
>> That is may be the infrun loops as it never gets stop signal. (the
>> output I earlier pasted).
>> Is it ok to provide patch for software single step like arm here?
>
> We only implement software single step on the targets don't have
> hardware single step capability, like arm.
>
>> (I am preparing one. It will have simulate aarch64 instruction set and
>> implement aarch64 version of functions of
>> arm_linux_software_single_step, arm_insert_single_step_breakpoint and
>> arm_get_next_pc.)
>
> Before you start it, better to get the reason why hw single step doesn't
> work on aarch64.
>
> --
> Yao (齐尧)

Re: Is there single step debugging support being added to aarch64-linux?

[Prafull Suryawanshi]

(sent too early, putting complete reply)

I debugged this one and found that when compared to gdb-arm,
gdb-aarch64 behaves little different.
Before even invoking software-single-step operations, gdb-arm invokes
Z0 packet before getting registers.
But gdb-aarch64 does not do it. It sets the Z0 after reading registers.
So in case gdb-arm, the Z0 is set to next pc value.
But for gdb-aarch64 it sets the Z0 at current pc only.

Below is logs when enabled remote_debug option.
for gdb-arm
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current
thread [Thread 2229] at 0xc01b2ddc
Sending packet: $Z0,c01b2de0,4#67...Ack

For gdb-aarch64,
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current
thread [Thread 3462] at 0xffffffc00021014c
Sending packet: $Z0,ffffffc00021014c,4#c8...Ack

As we can see, gdb-aarch64 puts Z0 (breakpoint) at same place where
current pc is. But gdb-arm puts breakpoint at just next pc.

Then I found that gdb-arm has below output
infrun: software single step trap for Thread 2229

So I implemented same for gdb-aarch64.

As for KGDB code for aarch64 do not have hardware breakpoint support.
(usermode does have)
Not sure if that could be issue.

Thanks,
Prafull


On Tue, Jun 16, 2015 at 10:47 AM, Prafull Suryawanshi
<prafull.net@gmail.com> wrote:
> I debugged this one and found that when compared to gdb-arm,
> gdb-aarch64 behaves little different.
> Before even invoking software-single-step operations, gdb-arm invokes
> Z0 packet before getting registers.
> But gdb-aarch64 does not do it. It sets the Z0 after reading registers.
> So in case gdb-arm, the Z0 is set to next pc value.
> But for gdb-aarch64 it sets the Z0 at current pc only.
>
> Below is logs when enabled remote_debug option.
> for gdb-arm
> infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current
> thread [Thread 2229] at 0xc01b2ddc
> Sending packet: $Z0,c01b2de0,4#67...Ack
>
>
> For gdb-aarch64,
> infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current
> thread [Thread 3462] at 0xffffffc00021014c
>
> On Mon, Jun 15, 2015 at 6:21 PM, Yao Qi <qiyaoltc@gmail.com> wrote:
>> Prafull Suryawanshi <prafull.net@gmail.com> writes:
>>
>>> I am not sure why hw stepper not works here (might be limitation of hw
>>> I am using).
>>
>> You'd better to check whether hw single step doesn't work in your case.
>>
>>> That is may be the infrun loops as it never gets stop signal. (the
>>> output I earlier pasted).
>>> Is it ok to provide patch for software single step like arm here?
>>
>> We only implement software single step on the targets don't have
>> hardware single step capability, like arm.
>>
>>> (I am preparing one. It will have simulate aarch64 instruction set and
>>> implement aarch64 version of functions of
>>> arm_linux_software_single_step, arm_insert_single_step_breakpoint and
>>> arm_get_next_pc.)
>>
>> Before you start it, better to get the reason why hw single step doesn't
>> work on aarch64.
>>
>> --
>> Yao (齐尧)