On Tue, Jan 31, 2006 at 05:36:13PM +0000, Maciej W. Rozycki wrote:
> On Tue, 31 Jan 2006, Johannes Stezenbach wrote:
> > I think (maybe in error ;-), that all binaries compiled for
> > a 32bit ABI, but a 64bit ISA, have this flag set, as the kernel
> > will refuse to execute 64bt code (i.e. not o32 or n32 ABI). Therefore,
> > shouldn't gdb also evaluate this flag when deciding about the ISA
> > register size?
> O32 implies 32-bit registers no matter what ISA is specified (while
> o32/MIPS-III is effectively o32/MIPS-II, o32/MIPS-IV makes a difference),
> therefore it's a bug. You should try sending your proposal to
> <email@example.com> instead. But I smell the problem is
> elsewhere -- mips_isa_regsize() shouldn't be called for the "cooked"
> registers and these are ones you should only see under Linux or, as a
> matter of fact, any hosted environment. See mips_register_type() for a
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