This is the mail archive of the gdb@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] Core files and the architecture vector


>>>>> "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



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