public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Phil Muldoon <pmuldoon@redhat.com>
Cc: frysk@sourceware.org
Subject: Re: Make CoredumpAction use Task.getRegisterBanks()
Date: Mon, 06 Aug 2007 10:03:00 -0000	[thread overview]
Message-ID: <1186394612.3766.37.camel@dijkstra.wildebeest.org> (raw)
In-Reply-To: <46B33940.6000005@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]

Hi Phil,

I tried to look up the "core file spec" but it seems no such thing exits
you just need to grep through binutils, gdb and kernel sources to figure
it all out it seems. Actually various searches all seem to finally point
to your frysk core file support (You are the expert now!) :)

On Fri, 2007-08-03 at 09:18 -0500, Phil Muldoon wrote:
> For the FP and fpxregs (which I am writing code for right now), I just 
> take the entire register buffer and dump it wholesale into the 
> appropriate note in the core file.

ACK. I saw bug #4890. It looks like whether or not the fp and fpx
register banks exist in the first place is platform specific. But I
guess this is another one of these "what does the kernel dump and how
does gdb read it back in" types of questions...

> > If we can match up the raw memory for each register bank between
> > ptrace/proc and core files from Task that would be ideal. Then the Isa
> > can just do the getRegisterByName() mapping. I'll watch your rewrite of
> > the core file stuff and see if this makes things easier and clearer (I
> > guess it will).
> >   
> The two requirements needed for core files are:
> 
> 1) Access to the raw memory behind the register via a ByteBuffer
> 2) Access to a logical method of getting registers by name, like 
> getRegisterByName()

And it can then provide those back for the core file as Task consumer as
right?

The question I am trying to answer is whether or not we can move
getRegisterBankBuffers() fully into the (ptrace) Task and let the Isa
use a call on the Task to provide the getRegisterByName() mapping
functionality from bank/numer to register name. Currently Task (or any
other Task consumer can) call back into the Isa to get at the actual
register banks, which is messy (and will produce the wrong results for
core file backed Tasks). So if we can match up the results of
Task.getRegisterBanks()/sendrecRegisterBanks() between ptrace/core Task
implementations then we could clean the Isa interface up and make the
Isa/Task user always get the correct result.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-08-06 10:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-30 16:53 Mark Wielaard
2007-07-30 17:44 ` Phil Muldoon
2007-07-31 12:03   ` Mark Wielaard
2007-08-01  0:27     ` Phil Muldoon
2007-08-02  8:28       ` Mark Wielaard
2007-08-03 14:18         ` Phil Muldoon
2007-08-06 10:03           ` Mark Wielaard [this message]
2007-08-22 21:33         ` Phil Muldoon

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=1186394612.3766.37.camel@dijkstra.wildebeest.org \
    --to=mark@klomp.org \
    --cc=frysk@sourceware.org \
    --cc=pmuldoon@redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).