Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: "H . J . Lu" <hjl@lucon.org>, gdb-patches@sources.redhat.com
Subject: Re: [hjl@lucon.org: Re: Does gdb 5.2 work with statically linked thread application under Linux?]
Date: Fri, 15 Mar 2002 19:56:00 -0000	[thread overview]
Message-ID: <3C92C275.5020304@cygnus.com> (raw)
In-Reply-To: <20020315222045.A3612@nevyn.them.org>

> The below just feels wrong.  The hook is pulling the thread stratum off 
>> the stack when, as far as I can tell, there is no compelling reason for 
>> doing this.
>> 
>> ``hey'' something has happened.  At this point, nothing has happened.
> 
> 
> What do you mean by "there is no compelling reason"?  Or how should
> this be handled?  The issue is that we do not want thread_db to be used
> at all for corefiles; we established that last time I touched this
> code, I just solved the problem wrong.  Once again, it doesn't work
> as-is, and unpushing matches the way the code was trying to behave.

I'd expect the thread stratum to be unpushed at the same time as the 
stratum below it is also unpushed.  In the code above, nothing is being 
unpushed so I can't see a reason to unpush the thread-db.

A few lines below the call-out is an unpush() call.  Shouldn't that 
unpush any stratum directly dependant on it?

If you don't want thread-db trying to push its self on top of a core 
stratum, why not check for core and ignore the event?

(GNU/Linux doesn't want the thread-db pushing its self on top of a CORE 
stratum but other OS's do (with an N:M thread:lwp mapping for instance).

> It is possible to have thread, process and core-file stratum 
>> simultaneously.  Changing the core-file shouldn't quietly zap the thread 
>> stratum on top of the process stratum.
>> 
>> I suspect the real problem here is a limitation in the current target 
>> frame work - it doesn't accomodate having two instances of the thread 
>> stratum active (one for the process and one for the core file) active at 
>> the same time :-(
> 
> 
> The target stack is almost entirely undocumented, unfortunately.  But
> from this it seems that changing targets should change the stack
> completely; be it a multi-arch thing or a local/remote thing (we've
> seen thread_db do the same thing in that case) or a local/core thing.

Most of GDB is almost entirely undocumented :-)  However, the user guide 
does describe the external interface to this feature:
http://sources.redhat.com/gdb/current/onlinedocs/gdb_16.html#SEC130

If I understand what you're saying correctly, yes.  Unfortunatly it 
isn't implemented that way.

Search for the words ``squashed sandwich'' in the mail archives :-)

Andrew


  reply	other threads:[~2002-03-16  3:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-13  9:50 Daniel Jacobowitz
2002-03-13  9:54 ` H . J . Lu
2002-03-15 18:51   ` Andrew Cagney
2002-03-15 19:20     ` Daniel Jacobowitz
2002-03-15 19:56       ` Andrew Cagney [this message]
2002-03-15 20:16         ` Daniel Jacobowitz
2002-03-15 20:48           ` Andrew Cagney

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=3C92C275.5020304@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=hjl@lucon.org \
    /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