Re: [RFC] New command 'gcore'

[Andrew Cagney <ac131313@cygnus.com>]

> To be more exact.  On a target such as Solaris where there is an N:M 
>  > relationship between (N) threads and (M) LWPs, a LWP iterator would be 
>  > needed.
> 
> You don't really need a thread->lwp mapping.  You just need to know
> how many LWPs there are, and what their lwpids are (so you can fetch
> their registers and also properly mark the note in the core file with
> the lwpid).  Presumably, the thread->lwp mapping would be contained
> in the memory image somewhere (e.g. the thread library's scheduler
> data structures).


Yes, sorry, I didn't quite say it right.  For solaris, GDB presents 
threads to the user.  Underneath the hood, GDB uses lib thread DB to map 
between LWPs and threads.  GDB, here, needs to put the LWP state into 
the core file.  Not the thread state.


> Actually, another interesting problem... you need to deal with the lazy
> FP context switching that many Unix systems do, as well.  E.g. when a
> process runs, even if it has previously used the FPU, it may be running
> on a processor which is different from the last processor it ran on,
> which means its FPU state could be somewhere else (that is, in another
> processor's FP registers, NOT in the process's PCB or in the current
> processor's FP registers), so you need to figure out some way to deal with
> that, as well.


But is that GDB's problem?  If the procfs / ptrace / ttrace interface is 
lieing (returning fp registers for the wrong LWP/thread) then we've 
worse problems than the above :-)

enjoy,
Andrew