public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Phil Muldoon <pmuldoon@redhat.com>
Cc: frysk@sourceware.org
Subject: Re: Leaving visible breakpoints in memory/core (Was: 	Breakpoint	stepping)
Date: Wed, 11 Jul 2007 09:47:00 -0000	[thread overview]
Message-ID: <1184147237.4322.18.camel@dijkstra.wildebeest.org> (raw)
In-Reply-To: <4693CAB6.8060809@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

Hi Phil,

On Tue, 2007-07-10 at 13:06 -0500, Phil Muldoon wrote:
> Well I think in the kernel dumping core there is nothing to be done with 
> 2) other than just let it happen. I just wonder if the entry-point of 
> the program being rewritten by Frysk in this scenario will cause 
> confusion. In the case of fcore, we can always strip all this stuff 
> beforehand, dump the core, and then put it all back. But in the case of 
> gcore and google's coredumper that won't be the case. A process has no 
> idea when a userland program like gcore/fcore is creating a coredump of it.
> 
> However until there is a better place to store this stuff other than at 
> the entry-point address, then I guess the question it sort of moot.

Yes, but the breakpoints instructions themselves are stored in the
image, only the original instruction is (if we use ssol, which is almost
never at this point) (re)stored at the entry-point address. And it is
the breakpoint instructions that we don't want to have in a fcore
result. Since both you and Andrew mentioned it I added it as second
scenario to the bug report, so I won't forget to create a testcase for
that.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-07-11  9: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 [this message]
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
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=1184147237.4322.18.camel@dijkstra.wildebeest.org \
    --to=mark@klomp.org \
    --cc=frysk@sourceware.org \
    --cc=pmuldoon@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).