(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.

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.

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."

This being a -tdep.c file, you probably don't need a mips-hosted gdb.

A --target=mips-linux-gnu build probably suffices.

(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.

(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.

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.

Proposed patch here: https://sourceware.org/ml/gdb-patches/2016-01/msg00134.html

I have a vague memory that this has been addressed already.

I just confirmed this is still happening.

No longer working on it.