public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Shahab Vahedi <shahab.vahedi@gmail.com>
To: Simon Marchi <simark@simark.ca>
Cc: gdb@sourceware.org, Shahab Vahedi <shahab@synopsys.com>
Subject: Re: Why enforcing sw_breakpoint_from_kind() implementation in GDBserver targets
Date: Thu, 11 Jun 2020 11:40:48 +0200	[thread overview]
Message-ID: <20200611094048.GA1270@gmail.com> (raw)
In-Reply-To: <8f80e486-cca4-819b-7316-329832df985f@simark.ca>

Hi Simon,

The ARC GDB client inserts the breakpoint by writing to memory (the
legacy way). With your explanations, I plan to add the Z0 packet
support to it.  Nevertheless, should it be still necessary to have
"sw_breakpoint_from_kind" in GDBserver as a mandatory method?

The rest follows:

On Wed, Jun 10, 2020 at 11:05:38PM -0400, Simon Marchi wrote:
> I don't understand your "This makes sense because we have a setup that looks
> like below", because that looks like a standard GDB/GDBserver setup used for
> other architectures.

I said it makes sense because the first question that pops into mind is
"If sw_breakpoint_from_kind should have been mandatory all the time,
then how come a debugging session with ARC GDBserver was able to insert
breakpoints?". The answer would be because ARC GDB client takes care of
it. In ARC case, as you concluded as well, the client asks the GDBserver
to write the opcodes to memory.
> When a breakpoint is inserted, what's the remote protocol packet used? Is it
> Z0, or is it a memory write operation that writes the breakpoint's opcode?  Z0
> is the "modern" way that provides more features (like target-side condition
> evaluation) and a memory write is the legacy fallback.
> sw_breakpoint_from_kind would be used if the Z0 packet was used, to translate
> the "kind" into an opcode.  Since you claim that sw_breakpoint_from_kind is
> not used, I guess that the breakpoint is inserted with a memory write operation.
> I'd look into why that is the case.  GDB tries Z0 first and falls back to the
> memory write if Z0 is not supported, so your GDBserver must not support it for
> some reason.

I am not sure why this could be the case. I will investigate that.
> > Last  but  not  least,  one  nitpick:  Even  though  I  have  added  the
> > implementation of "sw_breakpoint_from_kind", I have never  done  so  for
> > "breakpoint_kind_from_pc"    or    "breakpoint_kind_from_current_state".
> > These last two are supposed to provide  the  "kind"  that  will  be  the
> > input parameter for "sw_breakpoint_from_kind".  Therefore, even  if  the
> > new piece of "sw_breakpoint_from_kind" would be executed, that would  be
> > problematic.  I'm not sure what can be done about this but I think  _if_
> > "sw_breakpoint_from_kind"     should     be    mandatory,     so     are
> > "breakpoint_kind_from_pc" and "breakpoint_kind_from_current_state".
> 
> As mentioned above, the input for sw_breakpoint_from_kind can come from
> the Z0 packet, so it may make sense to have sw_breakpoint_from_kind without
> the others.  I am not sure off-hand when the others are used.
> 
> Simon

Shahab

  reply	other threads:[~2020-06-11  9:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-10 17:47 Shahab Vahedi
2020-06-11  3:05 ` Simon Marchi
2020-06-11  9:40   ` Shahab Vahedi [this message]
2020-06-11 10:35     ` Luis Machado
2020-06-11 11:00       ` Shahab Vahedi
2020-06-11 11:44         ` Shahab Vahedi
2020-06-12 11:04           ` Aktemur, Tankut Baris
2020-06-15 10:39             ` Shahab Vahedi
2020-06-16 13:15               ` Aktemur, Tankut Baris
2020-06-17 21:31                 ` Shahab Vahedi
2020-06-17 22:20                   ` Luis Machado
2020-06-11 14:51         ` Simon Marchi
2020-06-15  8:54           ` Metzger, Markus T
2020-06-17  0:40             ` Maciej W. Rozycki
2020-06-18  8:11               ` Metzger, Markus T
2020-06-18  9:13                 ` Maciej W. Rozycki
2020-06-18 10:29                   ` Metzger, Markus T
2020-06-18 11:03                     ` Maciej W. Rozycki
2020-06-18 11:11                       ` Metzger, Markus T
2020-06-11 21:21 ` Martin Simmons

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=20200611094048.GA1270@gmail.com \
    --to=shahab.vahedi@gmail.com \
    --cc=gdb@sourceware.org \
    --cc=shahab@synopsys.com \
    --cc=simark@simark.ca \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).