expected behavior of GNU/Linux gcore and corefiles

[Andrew Cagney]

> On Sat, Mar 01, 2003 at 10:16:39PM -0500, Andrew Cagney wrote:
> 
>> (notes from a hallway conversation, I had a recollection that, at some 
>> stage, the attempt to load libthread db over a core file on GNU/Linux 
>> was disabled.)
>> 
>> When using GDB on a live threaded program that puts all threads into 
>> tight infinite loops (while (1);), I'll do something like:
>> 
>>     $ ./a.out &
>>     Pid 1234
>>     $ gdb ./a.out 1234
>>     (gdb) info threads
>>     ....
>>     (gdb) quit
>> 
>> As a user I'd also expect sequences such as:
>> 
>>     $ kill -QUIT 1234
>>     $ gdb ./a.out core
>>     (gdb) info threads
>>     ....
>>     (gdb) quit
>> 
>> and:
>> 
>>     $ gcore 1234
>>     $ gdb ./a.out core
>>     (gdb) info threads
>>     ....
>>     (gdb) quit
> 
> 
> Hmm, what platform is that?  I've never seen a GNU/Linux
> implementation, but I'm a youngun.

FreeBSD, solaris.  This is the `expected behavior'.

>> 
>> and:
>> 
>>     $ gdb ./a.out 1234
>>     (gdb) gcore
>>     (gdb) quit
>>     $ gdb ./a.out core
>>     (gdb) info threads
>> 
>> to all come back with effectively the same output.  Further, on both 
>> live and corefile targets, I'd expect to be able to select/examine each 
>> thread vis:
>> 
>>     (gdb) thread 5
>>     11    i = i + 1;
>>     (gdb) list
>>     10    __thread__ i = 1;
>>     11    i = i + 1;
>>     (gdb) print i
>>     $1 = 1
>> 
>> (which would involve thread local storage).
>> 
>> Two problems come to mind:
>> 
>> - Is the kernel including all the raw information needed to do this in 
>> the core file?
> 
> 
> Some platforms yes, some platforms no.  I've had Linux patches to do
> this for some time.  I believe kernels as of 2.5.50 or so do it also.

Sounds like bugs.  If GDB is to give the user the best ptrace experience 
then GDB will need that information.

>> - For GDB to completly implement the above, is it forced to use 
>> libthread-db?
> 
> 
> Not necessarily.
> Here's the added value we get from libthread_db right now, on "normal"
> GNU/Linux threading (either LinuxThreads or NPTL, but not including the
> M-N stuff that NGPT does):
>   - Thread IDs, instead of just LWP IDs.  Big deal.

My point is that this _is_ a big deal.

GDB, in conjunction with libthread-db, should provide this interface. 
In fact, GDB+libthread-db should be providing a lot more:

	`info mutex'
	`info lwp'

It's the same situtation as for source code debugging.  While the user 
normally only views source code and variables (i.e., threads), GDB does 
also allow the user to open the bonnet and poke around in the registers 
and assembly (i.e., the lwp layer).

>   - Thread local storage offsets.
> 
> We could do find TLS areas with a per-architecture hook; libthread_db
> finds the TLS area by grubbing through the thread descriptor, but given
> that we have each LWP's state we could just do it in the
> platform-mandated way (i.e. examining the registers in question, etc.)
> 
> I don't know offhand if the necessary information for Alpha, i386, etc.
> TLS is in core files - i.e. platforms where it's more than just a
> register.

Per above, sounds like a bug.

[...]


> Thread_db is a great interface for querying threads.  It's not so good
> for debugging them; for a case in point see my messages about the FAIL
> at the end of print-threads.exp.  Thread_db does not interact well with
> debugging the thread manager itself, which is a very important feature
> for me.

And that was a bug.  I'm told that the new libthread-db code dropped the 
manager thread and, in the process, eliminated the problem.

Andrew