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: [rfa] Include the LWP in thread-db's PTIDs


On Mon, Oct 11, 2004 at 12:16:46PM -0400, Andrew Cagney wrote:
> >I hadn't thought about the core issue; I'll do some pondering. However,
> >I don't think your comment is quite right.  Thread_db can not be
> >layered over core files, we've already decided that - it's too iffy to
> >find the right thread_db, not to mention cross-debugging issues.  And
> >similarly we can't use it for remote thread debugging.  Thread_db only
> >makes any sense on top of local, running, native threads.
> 
> "we"'ve definitly not decided this.
> 
> Long ago you committed a hack to stop GDB layering thread-db over core 
> files.  It was to stop GDB barfing on native GNU/Linux core files.  It 
> had the side effect of breaking threads on all other systems, namely 
> solaris.  What keeps being pointing out is that thread-db should be 
> loaded over a core file, and not doing it is broken.
> 
> If we try it and it barfs, we've a bug.  But what we've not got is an 
> excuse for hobble native support (just because embedeed debuging is "iffy").

Huh?  It was a change to thread-db.c which has never been used for
Solaris, so I haven't got any idea what you are talking about.  I did
not break Solaris threads.

Also, it was an approved patch.  Michael responded at the end of the
thread saying that he agreed it was the right thing not to use
thread_db on core files.  Yes, there was a lot of disagreement before
that; but before the patch was committed the thread-db.c maintainer
agreed that we should not to use thread_db in this case.  I think I'm
justified in saying that "we" have decided this.

-- 
Daniel Jacobowitz


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