On Wed, Feb 01, 2006, Daniel Jacobowitz wrote: > All of this code is flat-out wrong, as far as I'm concerned. I have a > project underway which will fix it, as a nice side effect. > > GDB is trying to do something confusing, but admirable, here. When > you're running on a 64-bit system the full 64 bits are always there: > even if the binary only uses half of them (is this true in Linux? I > don't remember if the relevant control bits get fudged, it's been a > while; it's definitely true on some other systems). Thus it's possible > for a bogus instruction to corrupt the top half of a register, leading > to otherwise inexplicable problems. > > So if the remote stub knows about 64-bit registers, it should report > them to GDB, and GDB should accept and display them, and still handle > 32-bit frames. If the remote stub doesn't, then there's no option but > to report the 32-bit registers. > > Really, GDB ought to (and soon will I hope) autodetect which ones were > sent. If I understand this correctly, gdbserver should check the register size supported by the OS, and communicate this to gdb? I'm using a Linux kernel with CONFIG_32BIT, and if I understand the ptrace interface correctly, the registers as seen through ptrace are 32bit then, even though the CPU has 64bit registers. (I have no idea if the cp0 status suggested by others in this thread reflect CONFIG_32BIT vs. CONFIG_64BIT on Linux.) Anyway, is a better workaround _now_ for gdb-6.[34] than the patch to mips_register_type()? Thanks, Johannes
