From: Andrew Cagney <ac131313@cygnus.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb@sources.redhat.com
Subject: Re: GDB broken on MIPS targets with unmarked binaries
Date: Wed, 05 Jun 2002 13:44:00 -0000 [thread overview]
Message-ID: <3CFE7825.2030001@cygnus.com> (raw)
In-Reply-To: <20020605200429.GA7956@nevyn.them.org>
> There's an interesting crash on startup in a mips-elf GDB nowadays... the
> code reads:
>
> default:
> tdep->mips_abi_string = "default";
> tdep->mips_default_saved_regsize = MIPS_REGSIZE;
> tdep->mips_default_stack_argsize = MIPS_REGSIZE;
> tdep->mips_fp_register_double = (REGISTER_VIRTUAL_SIZE (FP0_REGNUM) == 8);
> tdep->mips_last_arg_regnum = A0_REGNUM + 8 - 1;
> tdep->mips_last_fp_arg_regnum = FPA0_REGNUM + 8 - 1;
> tdep->mips_regs_have_home_p = 1;
> tdep->gdb_target_is_mips64 = 0;
> tdep->default_mask_address_p = 0;
> set_gdbarch_long_bit (gdbarch, 32);
> set_gdbarch_ptr_bit (gdbarch, 32);
> set_gdbarch_long_long_bit (gdbarch, 64);
> break;
>
> Something brought in recently, probably by the OS ABI changes if I had to
> guess, is causing the check of REGISTER_VIRTUAL_SIZE to fail. I've no idea
> why. Compiling a mips-elf (not mips-linux, which sets MIPS_DEFAULT_ABI) and
> running gdb on an unmarked ELF binary reproduces this.
I'd suspect this:
2002-05-08 Andrew Cagney <ac131313@redhat.com>
* gdbarch.sh (init_gdbarch_swap): Do not clear the swap section.
(clear_gdbarch_swap): New function.
(initialize_non_multiarch): Call.
(gdbarch_update_p): Before calling init(), swap out and clear the
existing architecture.
* gdbarch.c: Regenerate.
The comment from arm-tdep.c should help explain why the above code is
broken:
/* We can't use NUM_REGS nor NUM_PSEUDO_REGS here, since that still
references the old architecture vector, not the one we are
building here. */
prologue_cache.saved_regs = (CORE_ADDR *)
xcalloc (1, (sizeof (CORE_ADDR)
* (gdbarch_num_regs (gdbarch)
+ gdbarch_num_pseudo_regs (gdbarch))));
As far as I can tell though, REGISTER_VIRTUAL_SIZE expands to
REGISTER_VIRTUAL_TYPE which is still a macro?
Andrew
next prev parent reply other threads:[~2002-06-05 20:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-05 13:08 Daniel Jacobowitz
2002-06-05 13:44 ` Andrew Cagney [this message]
2002-06-05 14:03 ` Daniel Jacobowitz
2002-06-05 14:12 ` Daniel Jacobowitz
2002-06-05 14:41 ` Andrew Cagney
2002-06-06 18:44 ` Daniel Jacobowitz
2002-06-07 12:55 ` Andrew Cagney
2002-06-07 13:07 ` Daniel Jacobowitz
2002-06-07 13:27 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3CFE7825.2030001@cygnus.com \
--to=ac131313@cygnus.com \
--cc=drow@mvista.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox