Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jason R Thorpe <thorpej@wasabisystems.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: msnyder@cygnus.com, Eli Zaretskii <eliz@is.elta.co.il>,
	gdb-patches@sources.redhat.com
Subject: Re: [RFC] New command 'gcore'
Date: Wed, 12 Dec 2001 17:35:00 -0000	[thread overview]
Message-ID: <20011212173359.L28715@dr-evil.shagadelic.org> (raw)
In-Reply-To: <3C18018E.9080902@cygnus.com>; from ac131313@cygnus.com on Wed, Dec 12, 2001 at 05:17:02PM -0800

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>


  reply	other threads:[~2001-12-13  1:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-12 14:17 Michael Snyder
2001-12-12 15:05 ` Eli Zaretskii
2001-12-12 15:29   ` Jason R Thorpe
2001-12-12 17:17     ` Andrew Cagney
2001-12-12 17:35       ` Jason R Thorpe [this message]
2001-12-12 17:48         ` Andrew Cagney
2001-12-12 18:06           ` Jason R Thorpe
2001-12-13 10:50             ` Andrew Cagney
2001-12-12 15:35 ` Kevin Buettner
2001-12-13 11:17   ` Michael Snyder
2001-12-26 12:32   ` Michael Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20011212173359.L28715@dr-evil.shagadelic.org \
    --to=thorpej@wasabisystems.com \
    --cc=ac131313@cygnus.com \
    --cc=eliz@is.elta.co.il \
    --cc=gdb-patches@sources.redhat.com \
    --cc=msnyder@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox