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 > <gdb-patches@xxxxxxxxxxxxxxxxxx> 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 > start. 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. -- Daniel Jacobowitz CodeSourcery
