Regcache changes broke MIPS

Regcache changes broke MIPS

[Daniel Jacobowitz]

A native MIPS/Linux GDB no longer starts.

The segfault is:

#0  0x004aab34 in mips_register_raw_size (reg_nr=268436760) at ../../src-gdblinks/gdb/mips-tdep.c:424
#1  0x005407a4 in build_regcache () at ../../src-gdblinks/gdb/regcache.c:789
#2  0x005407f4 in _initialize_regcache () at ../../src-gdblinks/gdb/regcache.c:803
#3  0x00526fcc in initialize_all_files () at init.c:94
#4  0x005197d0 in gdb_init (argv0=0x7fff7e00 "/opt/src/binutils/obj-src-mipshost/gdb/testsuite/../gdb")
    at ../../src-gdblinks/gdb/top.c:2070
#5  0x00431a04 in captured_main (data=0x10000518) at ../../src-gdblinks/gdb/main.c:483
#6  0x005151c0 in do_catch_errors (uiout=0x10000518, data=0x720d58) at ../../src-gdblinks/gdb/top.c:491
#7  0x00515000 in catcher (func=0x51518c <do_catch_errors>, func_uiout=0x100021a0, 
    func_args=0x7fff7c90, func_val=0x7fff7c9c, func_caught=0x7fff7c98, errstring=0x70eadc "", mask=6)
    at ../../src-gdblinks/gdb/top.c:423
#8  0x00515254 in catch_errors (func=0x100021a0 <def_uiout>, func_args=0x98, 
    errstring=0xa746e69 <Address 0xa746e69 out of bounds>, mask=1685217640)
    at ../../src-gdblinks/gdb/top.c:503
#9  0x004329ac in main (argc=4396696, argv=0x7fff7cc0) at ../../src-gdblinks/gdb/main.c:725

at:
419     mips_register_raw_size (int reg_nr)
420     {
421       if (mips64_transfers_32bit_regs_p)
422         return REGISTER_VIRTUAL_SIZE (reg_nr);
423       else if (reg_nr >= FP0_REGNUM && reg_nr < FP0_REGNUM + 32
424                && FP_REGISTER_DOUBLE)
425         /* For MIPS_ABI_N32 (for example) we need 8 byte floating point
426            registers.  */
427         return 8;
428       else


I assume that this is because the target has not been initialized yet:
#if GDB_MULTI_ARCH
#undef FP_REGISTER_DOUBLE
#define FP_REGISTER_DOUBLE (gdbarch_tdep (current_gdbarch)->mips_fp_register_double)
#endif

You can't use multi-arched macros from _initialize_regcache, I think.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Regcache changes broke MIPS

[Andrew Cagney]

>  mips_register_raw_size (int reg_nr)
> 420     {
> 421       if (mips64_transfers_32bit_regs_p)
> 422         return REGISTER_VIRTUAL_SIZE (reg_nr);
> 423       else if (reg_nr >= FP0_REGNUM && reg_nr < FP0_REGNUM + 32
> 424                && FP_REGISTER_DOUBLE)
> 425         /* For MIPS_ABI_N32 (for example) we need 8 byte floating point
> 426            registers.  */
> 427         return 8;
> 428       else
> 
> 
> I assume that this is because the target has not been initialized yet:
> #if GDB_MULTI_ARCH
> #undef FP_REGISTER_DOUBLE
> #define FP_REGISTER_DOUBLE (gdbarch_tdep (current_gdbarch)->mips_fp_register_double)
> #endif
> 
> You can't use multi-arched macros from _initialize_regcache, I think.


Grumph.

Because GDB isn't 100% multi-arch, it ends up having to use target 
macros from within _initialize_*().  Otherwize non- multi-arch code 
won't start up right.  When multi-arch is enabled, a dummy multi-arch 
vector is used.

Anyway, I think there is something even more messed up here.  First, I'm 
not sure why that function was called from within an _initialize*() 
function.  Secondly, the logic just looks backwards.

I'll do some pokeing.

enjoy,
Andrew

Re: Regcache changes broke MIPS

[Andrew Cagney]

> Grumph.
> 
> Because GDB isn't 100% multi-arch, it ends up having to use target macros from within _initialize_*().  Otherwize non- multi-arch code won't start up right.  When multi-arch is enabled, a dummy multi-arch vector is used.
> 
> Anyway, I think there is something even more messed up here.  First, I'm not sure why that function was called from within an _initialize*() function.  Secondly, the logic just looks backwards.
> 
> I'll do some pokeing.


Hmm, doctor the patient is worse than we thought (and how ironic, this 
one is my target).

Briefly, the MIPS still defines certain methods (REGISTER_RAW_SIZE() at 
least) as macro's mapped onto functions instead of true multi-arch 
methods.  That is why they are being called when they shouldn't.

I came up with a patch that fixed just REGISTER_RAW_SIZE() but that 
didn't fix it - suspect I need to find more.

enjoy?
Andrew

Re: Regcache changes broke MIPS

[Daniel Jacobowitz]

On Sun, Dec 09, 2001 at 02:52:37PM -0800, Andrew Cagney wrote:
> >Grumph.
> >
> >Because GDB isn't 100% multi-arch, it ends up having to use target macros 
> >from within _initialize_*().  Otherwize non- multi-arch code won't start up 
> >right.  When multi-arch is enabled, a dummy multi-arch vector is used.
> >
> >Anyway, I think there is something even more messed up here.  First, I'm 
> >not sure why that function was called from within an _initialize*() 
> >function.  Secondly, the logic just looks backwards.
> >
> >I'll do some pokeing.
> 
> 
> Hmm, doctor the patient is worse than we thought (and how ironic, this 
> one is my target).
> 
> Briefly, the MIPS still defines certain methods (REGISTER_RAW_SIZE() at 
> least) as macro's mapped onto functions instead of true multi-arch 
> methods.  That is why they are being called when they shouldn't.
> 
> I came up with a patch that fixed just REGISTER_RAW_SIZE() but that 
> didn't fix it - suspect I need to find more.

I think I follow.  Do you actually currently build the register cache
with dummy values (on a multiarch target) and then rebuild it after
gdbarch is initialized?

It seems like there should be a way to register a post-gdbarch,
non-multi-arch-target init function to avoid this.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Regcache changes broke MIPS

[Andrew Cagney]

> Hmm, doctor the patient is worse than we thought (and how ironic, this 
>> one is my target).
>> 
>> Briefly, the MIPS still defines certain methods (REGISTER_RAW_SIZE() at 
>> least) as macro's mapped onto functions instead of true multi-arch 
>> methods.  That is why they are being called when they shouldn't.
>> 
>> I came up with a patch that fixed just REGISTER_RAW_SIZE() but that 
>> didn't fix it - suspect I need to find more.
> 
> 
> I think I follow.  Do you actually currently build the register cache
> with dummy values (on a multiarch target) and then rebuild it after
> gdbarch is initialized?


I fixed REGISTER_RAW_SIZE() and it died in what appeared to be 
REGISTER_BYTE() .....

At present the architecture gets built three times (!!!):

	o	dummy architecture

	o	default architecture

	o	executables architecture

The first one goes, once the non multi-arch targets are removed.


> It seems like there should be a way to register a post-gdbarch,
> non-multi-arch-target init function to avoid this.


That is hopefully unnecessary.  Just need to convert a few more MIPS macros.

	Andrew