Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Prafull Suryawanshi <prafull.net@gmail.com>
To: pinskia@gmail.com
Cc: Andreas Schwab <schwab@suse.de>,
	"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: Is there single step debugging support being added to aarch64-linux?
Date: Mon, 15 Jun 2015 11:48:00 -0000	[thread overview]
Message-ID: <CAJgVtDXpEWCs8oWzDcUydNA4XAQuVFrMffOk824DkTZ1cReHhQ@mail.gmail.com> (raw)
In-Reply-To: <D8AF3977-52F1-4976-8F90-237ADA8FC267@gmail.com>

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."


  reply	other threads:[~2015-06-15 11:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-15 10:21 Prafull Suryawanshi
2015-06-15 10:38 ` Andreas Schwab
2015-06-15 10:57   ` Prafull Suryawanshi
2015-06-15 11:03     ` Andreas Schwab
2015-06-15 11:07     ` Prafull Suryawanshi
2015-06-15 11:20       ` pinskia
2015-06-15 11:48         ` Prafull Suryawanshi [this message]
2015-06-15 11:57           ` pinskia
2015-06-15 12:12             ` Prafull Suryawanshi
2015-06-15 12:51           ` Yao Qi
2015-06-16  5:18             ` Prafull Suryawanshi
2015-06-16  5:22               ` Prafull Suryawanshi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJgVtDXpEWCs8oWzDcUydNA4XAQuVFrMffOk824DkTZ1cReHhQ@mail.gmail.com \
    --to=prafull.net@gmail.com \
    --cc=gdb@sourceware.org \
    --cc=pinskia@gmail.com \
    --cc=schwab@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox