public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: archer@sourceware.org, utrace-devel@redhat.com
Subject: Re: gdbstub initial code, v8
Date: Mon, 06 Sep 2010 18:31:00 -0000	[thread overview]
Message-ID: <20100906183142.GA3256@host1.dyn.jankratochvil.net> (raw)
In-Reply-To: <20100906181808.GA22839@redhat.com>

On Mon, 06 Sep 2010 20:18:08 +0200, Oleg Nesterov wrote:
> On 09/05, Jan Kratochvil wrote:
> > On Sat, 04 Sep 2010 00:40:47 +0200, Oleg Nesterov wrote:
> > memory writes
> 
> Yes. This is simple.
> 
> > (also to put in breakpoints):
> 
> And this is not clear to me, I need your help ;)

Sorry, I just meant that by implementing the memory writes breakpoints
automatically start to work.


> What should ugdb know about breakpoints? I played with the real
> gdbserver, and afaics gdb just changes the tracee's memory and
> inserts 0xcc (int 3). But gdb.info mentions "Z TYPE,ADDR,KIND"
> packets.

I believe it is described by:
  /* If GDB wanted this thread to single step, we always want to
     report the SIGTRAP, and let GDB handle it.  Watchpoints should
     always be reported.  So should signals we can't explain.  A
     SIGTRAP we can't explain could be a GDB breakpoint --- we may or
     not support Z0 breakpoints.  If we do, we're be able to handle
     GDB breakpoints on top of internal breakpoints, by handling the
     internal breakpoint and still reporting the event to GDB.  If we
     don't, we're out of luck, GDB won't see the breakpoint hit.  */


> So, what should ugdb do? Just implement memory write (M or X)
> and then report SIGTRAP like gdbserver does?

Therefore until you track some ugdb-specific software(*) breakpoints ugdb does
not need to support Z0 IMO.  I guess ugdb will never have to support these:
thread-related(?) and tracepoint ones.

(*) That is the memory-type one.  There are also `hbreak' breakpoints via the
    CPU debug registers.


Thanks,
Jan

  reply	other threads:[~2010-09-06 18:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-03 22:44 Oleg Nesterov
2010-09-05 19:41 ` Jan Kratochvil
2010-09-06 18:21   ` Oleg Nesterov
2010-09-06 18:31     ` Jan Kratochvil [this message]
2010-09-06 20:48       ` Oleg Nesterov
2010-09-07  2:59         ` Frank Ch. Eigler
2010-09-08 19:24           ` Oleg Nesterov
2010-09-10 10:02           ` Roland McGrath
2010-09-06 18:27 ` gdbstub initial code, v8 && ptrace Oleg Nesterov
2010-09-06 19:45   ` Oleg Nesterov
2010-09-06 21:02     ` Oleg Nesterov
2010-09-10 10:10       ` Roland McGrath
2010-09-10 19:10         ` Oleg Nesterov
2010-10-13  7:14           ` Roland McGrath
2010-10-15 13:57             ` Oleg Nesterov

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=20100906183142.GA3256@host1.dyn.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=archer@sourceware.org \
    --cc=oleg@redhat.com \
    --cc=utrace-devel@redhat.com \
    /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).