From: Daniel Jacobowitz <drow@false.org>
To: Mark Kettenis <mark.kettenis@xs4all.nl>,
gdb-patches@sourceware.org, Kevin Buettner <kevinb@redhat.com>
Subject: Re: [rfc / remote protocol] Remote shared library events
Date: Mon, 21 May 2007 12:00:00 -0000 [thread overview]
Message-ID: <20070521115947.GA30013@caradoc.them.org> (raw)
In-Reply-To: <20070515132826.GA18923@caradoc.them.org>
On Tue, May 15, 2007 at 09:28:26AM -0400, Daniel Jacobowitz wrote:
> Here are just the infrun parts. They've gained a test case for the
> trickiest part, a cleanup, a better changelog, and an explanation.
>
> First of all, I don't remember why I was testing
> inferior_ignoring_startup_exec_events in the last version of this
> patch. I discovered that now there are no references to it (there may
> have been one when I wrote it). I didn't really need it, so I garbage
> collected it.
>
> Secondly, I needed to make TARGET_WAITKIND_LOADED support work with
> the current solib.c implementation. You can tell it hasn't been used
> in a while since it was conditioned on "#ifdef SOLIB_ADD"; there are
> almost no definitions of that left.
>
> Third, while debugging shared library support for SymbianOS I kept
> encountering an unpleasant surprise. I would disconnect from the
> remote target when it was stopped at a load event (usually because my
> GDB crashed :-). When I reconnected, GDB would automatically resume
> the program! That's where the ugly stop_soon test was in the last
> version of this. For this version, I reviewed every setting and use
> of stop_soon and decided that none of them quite matched the case in
> stop_remote, so I added a new STOP_QUIETLY_REMOTE (and some comments
> about it). This is just like STOP_QUIETLY_NO_SIGSTOP except that it
> does not need to hide a SIGSTOP if it finds one. It means we're
> connecting to the target for the first time, so we shouldn't decide to
> resume it without giving the user a chance to look around.
>
> I hope this version is clearer; what do you think of it?
Hi Mark, Kevin,
Did either of you have a chance to look at this? You both had
concerns about the infrun parts of the combined patch, so I'd like to
make sure this version is better and clearer before I go on with the
other pieces.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2007-05-21 12:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-09 20:16 Daniel Jacobowitz
2007-05-10 3:18 ` Eli Zaretskii
2007-05-11 17:24 ` Daniel Jacobowitz
2007-05-11 17:39 ` Eli Zaretskii
2007-05-10 21:35 ` Mark Kettenis
2007-05-11 3:35 ` Daniel Jacobowitz
2007-05-15 13:28 ` Daniel Jacobowitz
2007-05-21 12:00 ` Daniel Jacobowitz [this message]
2007-07-02 21:37 ` Daniel Jacobowitz
2007-05-11 18:02 ` Kevin Buettner
2007-05-11 18:21 ` Daniel Jacobowitz
2007-05-11 23:31 ` Pedro Alves
2007-05-16 22:59 ` Jim Blandy
2007-05-18 0:27 ` Daniel Jacobowitz
2007-05-18 16:04 ` Jim Blandy
2007-05-18 16:10 ` Daniel Jacobowitz
2007-05-18 16:49 ` Jim Blandy
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=20070521115947.GA30013@caradoc.them.org \
--to=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=kevinb@redhat.com \
--cc=mark.kettenis@xs4all.nl \
/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