From: Paul Koning <pkoning@equallogic.com>
To: drow@mvista.com
Cc: kettenis@chello.nl, gdb@sources.redhat.com
Subject: Re: [RFC] Core files and the architecture vector
Date: Mon, 13 Oct 2003 13:44:00 -0000 [thread overview]
Message-ID: <16266.44095.175000.85307@gargle.gargle.HOWL> (raw)
In-Reply-To: <20031011222622.GB7209@nevyn.them.org>
>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
Daniel> I'll respond to the rest of your message later but... On
Daniel> Sun, Oct 12, 2003 at 12:07:32AM +0200, Mark Kettenis wrote:
>> Let me elaborate on the second point. When a 32-bit executable
>> running on FreeBSD/amd64 or GNU/Linux x86-64 dumps, it produces an
>> 64-bit ELF core file. To be able to make any sense out of this
>> core file, we'll need the 64-bit register set definitions that are
>> provided by the regset_from_core_section method from the 64-bit
>> architecture
Daniel> I still don't think this bit makes much sense. The process
Daniel> sees only 32-bit registers; the core should contain only
Daniel> 32-bit registers. Intuitively at least. On the other hand,
Daniel> on MIPS64 (and x86-64?) a 32-bit process can actually access
Daniel> 64-bit registers. It's forbidden to and the context
Daniel> switching won't cope right, but it can be done anyway.
Precisely for that reason the core file should contain the real
registers, not the truncated ones. Taking a MIPS example: if
supposedly 32-bit code somehow manages to have the upper 32 bits of
the registers NOT be sign-extension as they are supposed to be, then
Bad Things will happen to that program. If the core file only shows
the truncated registers, you can't see what went wrong.
paul
next prev parent reply other threads:[~2003-10-13 13:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-11 22:07 Mark Kettenis
2003-10-11 22:26 ` Daniel Jacobowitz
2003-10-11 22:43 ` Mark Kettenis
2003-10-11 23:57 ` Andrew Cagney
2003-10-13 13:44 ` Paul Koning [this message]
2003-10-11 23:07 ` Andrew Cagney
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=16266.44095.175000.85307@gargle.gargle.HOWL \
--to=pkoning@equallogic.com \
--cc=drow@mvista.com \
--cc=gdb@sources.redhat.com \
--cc=kettenis@chello.nl \
/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).