From: "J. Johnston" <jjohnstn@redhat.com>
To: Mark Kettenis <kettenis@chello.nl>
Cc: Daniel Jacobowitz <drow@mvista.com>, gdb-patches@sources.redhat.com
Subject: Re: RFA: Patch for corefile support
Date: Tue, 18 Feb 2003 17:31:00 -0000 [thread overview]
Message-ID: <3E526DDB.3050402@redhat.com> (raw)
In-Reply-To: <20030203233859.GA28591@nevyn.them.org>
Daniel Jacobowitz wrote:
> On Mon, Feb 03, 2003 at 05:58:19PM -0500, J. Johnston wrote:
>
>>
>>Daniel Jacobowitz wrote:
>>
>>>On Sat, Feb 01, 2003 at 02:22:02PM +0100, Mark Kettenis wrote:
>>>
>>>
>>>>"J. Johnston" <jjohnstn@redhat.com> writes:
>>>>
>>>>
>>>>
>>>>>The attached patch fixes a problem in gdb when a corefile is read in
>>>>>after a multithreaded application has been debugged. What happens is
>>>>>that
>>>>>the thread-db and lin-lwp layers are still around and run into internal
>>>>>errors.
>>>>>
>>>>>The solution is simply to unpush the thread-db ops in its mourn_inferior
>>>>>routine. If a corefile gets loaded, there is no thread-db to interfere.
>>>>>If another multi-threaded app gets loaded, the thread_db_new_objfile is
>>>>>designed to bring back the thread-db layer as needed.
>>>>>
>>>>>This fix solves another failure in the killed.exp testsuite as well.
>>>>>
>>>>>Ok to commit?
>>>>
>>>>Sorry, no. AFAICT this will break debugging programs that are
>>>>statically linked against libpthread. As a minimum, this code should
>>>>check keep_thread_db before unpushing the target, but even then, I'm
>>>>not sure whether this is really OK.
>>>
>>>
>>>Programs statically linked against libpthread are already broken. I
>>>have a patch to fix it, but it's so gross that I haven't posted it; I
>>>still can't think of a good way to do it.
>>>
>>>Given the way GDB treats targets, we seem to be waffling; someone fixes
>>>core file support and breaks static binaries, or vice versa.
>>>
>>
>>So, is there a scenario where my patch would be wrong? I am seeing what you
>>discussed. Statically linked multi-threaded programs don't work with gdb
>>because we never set up the thread_db_ops layer to begin with
>>(thread_db_new_objfile never gets called with a non-null objfile with
>>the target_has_execution flag on).
>
>
> I don't know. The whole way in which thread_db is initialized right
> now is a little bit confusing.
>
Mark, I haven't seen a response from you regarding this. Do you still oppose
the patch now that it is clear that statically linked threaded programs
never worked in the first place? If so, could you please elaborate.
-- Jefff J.
next prev parent reply other threads:[~2003-02-18 17:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-27 23:05 J. Johnston
2003-02-01 13:22 ` Mark Kettenis
2003-02-01 17:00 ` Daniel Jacobowitz
2003-02-03 22:58 ` J. Johnston
2003-02-03 23:39 ` Daniel Jacobowitz
2003-02-18 17:31 ` J. Johnston [this message]
2003-06-02 19:22 ` Michael Snyder
2003-06-03 20:03 ` J. Johnston
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=3E526DDB.3050402@redhat.com \
--to=jjohnstn@redhat.com \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
--cc=kettenis@chello.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