This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug corefiles/18964] [mips] 7.9 regression: internal-error: mips-tdep.c:1098: bad register size


https://sourceware.org/bugzilla/show_bug.cgi?id=18964

--- Comment #5 from Andreas Arnez <arnez at linux dot vnet.ibm.com> ---
(In reply to Pedro Alves from comment #4)
> This being a -tdep.c file, you probably don't need a mips-hosted gdb.
> 
> A --target=mips-linux-gnu build probably suffices.

Right, I can reproduce the problem with "set arch mips" followed by "target
core i386-biarch-core.core".  Not sure whether that's equivalent to Luis'
scenario.  Anyway, in my test there's a register size mismatch between the raw
PC register (regno 37, 4 bytes) and the pseudo-register representing the PC
(regno 116, 8 bytes).  The pseudo-register's size is derived from the
determined ABI (MIPS_ABI_N64), which is derived from the core file's bit size
(64).  The raw register's size is determined in mips_isa_regsize() and derived
from the gdbarch's bfd_arch_info (bfd_mips_arch in this case, which means
32-bit).  The use of bfd_arch_info is a fall-back when we don't have a valid
target description.  And that's the case because
mips_linux_core_read_description returns NULL for this invalid core file.

So, bottom line it seems to me that the problem is caused by the MIPS tdep code
being confused about the nature of the target's architecture, particularly its
bit size.

I don't have a suggestion for a patch, since my understanding of the existing
logic's purpose is still too vague.  Thus I'd prefer leaving it to a MIPS
expert to provide a fix.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]