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: [RFC] New command 'gcore'


On Wed, Dec 12, 2001 at 05:17:02PM -0800, Andrew Cagney wrote:

 > > 	* You need to know if a given chunk of the address space
 > > 	  should be dumped, even if it is mapped (consider a
 > > 	  memory-mapped device where reads produce side-effects).
 > 
 > 
 > That one is more interesting.  I suspect it might be best to punt this 
 > and leave finding the solution to those with the problem :-)

Eh, I guess.  But most Unix systems explcitly skip memory regions that
aren't file-backed or anonymous pages, so GDB should skip such regions,
too.

 > 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).

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.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>


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