Bug 18964 - [mips] 7.10.1 regression: internal-error: mips-tdep.c:1098: bad register size
Summary: [mips] 7.10.1 regression: internal-error: mips-tdep.c:1098: bad register size
Status: ASSIGNED
Alias: None
Product: gdb
Classification: Unclassified
Component: corefiles (show other bugs)
Version: 7.10
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on: 17808
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-15 14:57 IST by Jan Kratochvil
Modified: 2017-11-06 18:32 IST (History)
5 users (show)

See Also:
Host:
Target: mips-linux-gnu
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Kratochvil 2015-09-15 14:57:03 IST
+++ This bug was initially created as a clone of Bug #17808 +++

Expected output on a MIPS host:

./gdb -q -c ./i386-biarch-core.core 
gdb/mips-tdep.c:1098: internal-error: bad register size

core-file gdb.arch/i386-biarch-core.core
gdb/mips-tdep.c:1098: internal-error: bad register size
A problem internal to GDB has been detected,
further debugging may prove unreliable.^
Quit this debugging session? (y or n)
FAIL: gdb.arch/i386-biarch-core.exp: core-file (GDB internal error)

Probably:
8f0435f75e3c9676d2e177ce055fed3155fd9476 is the first bad commit
commit 8f0435f75e3c9676d2e177ce055fed3155fd9476
Author: Andreas Arnez <arnez@linux.vnet.ibm.com>
Date:   Fri Sep 12 08:42:48 2014 +0000
    Add 'regset' parameter to 'iterate_over_regset_sections_cb'
Message-Id: <1410538439-29791-1-git-send-email-arnez@linux.vnet.ibm.com>
Comment 1 Andreas Arnez 2015-09-15 18:18:33 IST
(In reply to Jan Kratochvil from comment #0)
> +++ This bug was initially created as a clone of Bug #17808 +++
> 
> Expected output on a MIPS host:
> 
> ./gdb -q -c ./i386-biarch-core.core 
> gdb/mips-tdep.c:1098: internal-error: bad register size

What version is this?  I don't see this assertion near line 1098 in upstream GDB or GDB 7.9.1.

And do you have more information?  A full backtrace might be helpful.  I don't have a MIPS host, so I can't reproduce this bug.

> Probably:
> 8f0435f75e3c9676d2e177ce055fed3155fd9476 is the first bad commit

Hm, nothing obvious here.  The patch doesn't directly touch the MIPS target support.
Comment 2 Luis Machado 2015-09-15 18:28:37 IST
The lines don't match because i have a slightly modified version of the sources. I'll give it a try with unmodified upstream sources, but the code is basically the same for that function.

I didn't investigate this further, but i suppose this is a missing adjustment in mips-tdep.c rather than something that was broken by another commit.
Comment 3 Luis Machado 2015-09-15 18:30:05 IST
Also, this is what i mentioned in the list post...

"The lines are a bit off, but basically we end up hitting the internal error at mips-tdep.c:mips_pseudo_register_read. I don't think the MIPS backend is currently crafted to handle reading unknown register blocks."
Comment 4 Pedro Alves 2015-09-15 18:32:57 IST
This being a -tdep.c file, you probably don't need a mips-hosted gdb.

A --target=mips-linux-gnu build probably suffices.
Comment 5 Andreas Arnez 2015-09-16 16:27:11 IST
(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.
Comment 6 Andreas Arnez 2015-09-16 17:25:34 IST
(In reply to Jan Kratochvil from comment #0)
> Probably:
> 8f0435f75e3c9676d2e177ce055fed3155fd9476 is the first bad commit
Note that I can't confirm this in my testing (see comment #5).  Instead, I see the same problem with the parent of that commit.
Comment 7 Luis Machado 2016-01-07 19:21:05 IST
It sounds like a reasonable solution is to bail out as soon as we figure out the core file doesn't have a suitable MIPS ISA/ABI combination. This would happen in the gdbarch_init phase, in which case GDB properly errors out with a message like this:

gdb.arch/i386-biarch-core.core": no core file handler recognizes format

The tricky part is when we happen to be lucky enough that the core file for a non-MIPS architecture really does look like a MIPS one, but with invalid data and alignments. But that's a pathological case, and i think we can settle on the improved handling of invalid core files in the MIPS backend.

For this particular testcase, i noticed we end up with a combination of ISA_MIPS16 and N64 ABI. That is surely invalid and we can detect that and, more generally, cases where we are trying to debug 64-bit ABI's with a 32-bit ISA/registers.
Comment 8 Luis Machado 2016-01-08 18:33:47 IST
Proposed patch here: https://sourceware.org/ml/gdb-patches/2016-01/msg00134.html
Comment 9 Luis Machado 2016-10-28 20:54:03 IST
I have a vague memory that this has been addressed already.
Comment 10 Luis Machado 2017-01-09 19:26:58 IST
I just confirmed this is still happening.
Comment 11 Luis Machado 2017-11-06 18:32:14 IST
No longer working on it.