This is the mail archive of the gdb@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: expected behavior of GNU/Linux gcore and corefiles


On Sun, Mar 02, 2003 at 01:31:08PM -0500, Andrew Cagney wrote:
> >On Sun, Mar 02, 2003 at 10:56:08AM -0500, Andrew Cagney wrote:
> >
> >>>On Sat, Mar 01, 2003 at 10:39:00PM -0500, Daniel Jacobowitz wrote:
> >>>
> >
> >>>>> My instincts tell me that, to completly implement the above 
> >>>>> functionality, GDB is always going to need libthread-db.  If GDB 
> >>could >>> implement the above on a core file without using libthread-db, 
> >>then GDB >>> could also implement the above on a live target also without 
> >>using >>> libthread-db.  This is because a core file is always going to 
> >>contain a >>> subset of the information made available via ptrace et.al.
> >
> >>>
> >>>
> >>>Oh, and one other thing that I like to mention when this comes up.  My
> >>>previous message was the implementation issues involved; this one's the
> >>>motivational issue.  Thread_db is not, and can't/shouldn't be,
> >>>available in a cross environment.  We have done a lot of work to make
> >>>GDB read corefiles in a cross environment; and at MontaVista we've seen
> >>>a large demand for this functionality from our customers.  So using
> >>>thread_db with corefiles doesn't meet our (GDB developers') goals, I
> >>>think.
> >
> >>
> >>Sorry, on this point, I'm lost.  What are you suggesting here?
> >
> >
> >My point is just that it's important for GDB to not require thread_db
> >when dealing with core files.   A lot of people seem to use e.g. Solaris
> >to debug core files and expect everything they would get from using GDB
> >natively; that's their expectation and so far we've been able to stay
> >pretty much there.
> 
> If that position means precluding certain native-only functionality?

Not exactly; if that native-only functionality precludes keeping what
we have now for non-thread_db setups and extending it.  For instance, I
think we should always be able to print LWP state (assuming a 1-1
mapping when we have no thread_db to ask for more information).  And I
think we should add support for TLS based only on LWPs, since it's not
dependent on the thread manager.  If we can't "info mutex" on a cross
corefile, well, that's the same as now.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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