public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Phil Muldoon <pmuldoon@redhat.com>
To: Mark Wielaard <mark@klomp.org>
Cc: Roland McGrath <roland@redhat.com>, frysk@sourceware.org
Subject: Re: Leaving visible breakpoints in memory/core (Was: Breakpoint	stepping)
Date: Tue, 17 Jul 2007 15:47:00 -0000	[thread overview]
Message-ID: <469CE468.7030006@redhat.com> (raw)
In-Reply-To: <1184601180.3628.53.camel@dijkstra.wildebeest.org>

Mark Wielaard wrote:
> But if you really wanted to then you could at least get the breakpoints
> instructions that frysk-core inserted from BreakpointAddresses (which I
> will soon extend with a handy getAllAdresses() method for fixing bug
> #4761), and then you can get the actual breakpoint instruction bytes
> used from the relevant Isa getBreakpointInstruction(). This is probably
> too low level though. And since you cannot guarantee that the created
> core file is read back through frysk (someone could be using gdb!) I
> don't know where you would actually put this information or how you
> would make all consumers know about both the original bytes and the
> breakpoint instructions in the image.
>   

What's the argument about just dumping the task's memory as is, with all 
breakpoints there? A corefile is a representation of that process and 
it's thread as it is at that time ...

And besides, this is only addressing a tiny corner case of someone 
running fcore on a process that is being debugged with Frysk at that 
time. I can't think of a scenario why I would do that. Can you? If they 
were debugging with GDB and fcore was run on that process, the included 
core image would have all the break point information.

It seems like a lot of work for a very small edge case?

Regards

Phil

  reply	other threads:[~2007-07-17 15:47 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-04 18:20 Breakpoint stepping Mark Wielaard
2007-07-05  4:45 ` Phil Muldoon
2007-07-05 12:39   ` Mark Wielaard
2007-07-10  9:59     ` Leaving visible breakpoints in memory/core (Was: Breakpoint stepping) Mark Wielaard
2007-07-10 13:52       ` Andrew Cagney
2007-07-10 18:06       ` Phil Muldoon
2007-07-11  9:47         ` Mark Wielaard
2007-07-12  2:49           ` Roland McGrath
2007-07-12 14:24             ` Phil Muldoon
2007-07-12 20:24               ` Roland McGrath
2007-07-16 15:57                 ` Mark Wielaard
2007-07-17 15:43                   ` Phil Muldoon
2007-07-17 17:06                     ` Mark Wielaard
2007-07-16 15:53               ` Mark Wielaard
2007-07-17 15:47                 ` Phil Muldoon [this message]
2007-07-17 17:08                   ` Mark Wielaard
2007-07-05 18:37 ` Breakpoint stepping Andrew Cagney
2007-07-23 12:19   ` Mark Wielaard
2007-07-10 10:39 ` Instruction parser (Was: Breakpoint stepping) Mark Wielaard
2007-07-10 10:50 ` Instruction breakpoint-stepping testsuite " Mark Wielaard
2007-07-16  9:19   ` [patch] " Mark Wielaard
2007-07-10 10:57 ` SSOL Area " Mark Wielaard

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=469CE468.7030006@redhat.com \
    --to=pmuldoon@redhat.com \
    --cc=frysk@sourceware.org \
    --cc=mark@klomp.org \
    --cc=roland@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).