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
next prev parent 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).