From: Mark Kettenis <kettenis@chello.nl>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFC: threads PREPARE_TO_PROCEED patch
Date: Fri, 14 Mar 2003 17:20:00 -0000 [thread overview]
Message-ID: <86of4d7tle.fsf@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: Daniel Jacobowitz's message of "Thu, 13 Mar 2003 18:32:51 -0500"
Daniel Jacobowitz <drow@mvista.com> writes:
> This patch aims to avoid problems when using a native GNU/Linux debugger
> (which supports threads) with a remote protocol stub that supports threads.
> lin_lwp_prepare_to_proceed gets called anyway, but it doesn't function,
> because the trap_ptid is (unsurprisingly) not set; since it's internal
> accounting for lin-lwp. This patch makes us use generic_prepare_to_proceed
> instead of the old default_prepare_to_proceed or lin_lwp_prepare_to_proceed;
> it can get everything it needs from infrun. If I recall correctly, it also,
> as per the FIXME, supports switching threads better than the lin_lwp version
> did. But I haven't tested that in a long time.
>
> This is a patch from last year, just before 5.3 was branched. At the time
> it was decided to be generally right, but too risky for 5.3. Well, now I've
> gone and sat on it for too long, and we're coming up on 5.4. But I've been
> using this patch since August without any problems. Depending on consensus
> I'd like to check it in either before or after we branch for release.
>
> Thoughts, thread maintainers?
I'm not quite sure whether changing the gdbarch default is a good
idea, but replacing lin_lwp_prepare_to_proceed with
generic_prepare_to_proceed has been the intention all along.
Mark
next prev parent reply other threads:[~2003-03-14 17:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-13 23:32 Daniel Jacobowitz
2003-03-14 17:20 ` Mark Kettenis [this message]
2003-03-14 18:35 ` Daniel Jacobowitz
2003-03-15 20:39 ` Mark Kettenis
2003-03-15 20:51 ` Daniel Jacobowitz
2003-03-16 21:24 ` Andrew Cagney
2003-05-26 19:57 ` Andrew Cagney
2003-05-26 20:05 ` Daniel Jacobowitz
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=86of4d7tle.fsf@elgar.kettenis.dyndns.org \
--to=kettenis@chello.nl \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.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