This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [hjl@lucon.org: Re: Does gdb 5.2 work with statically linked thread application under Linux?]


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]