This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Handle loading improper core files gracefully in the mips backend.
- From: Luis Machado <lgustavo at codesourcery dot com>
- To: "Maciej W. Rozycki" <macro at imgtec dot com>, Pedro Alves <palves at redhat dot com>
- Cc: <gdb-patches at sourceware dot org>, Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Date: Fri, 5 Feb 2016 09:29:19 -0200
- Subject: Re: [PATCH] Handle loading improper core files gracefully in the mips backend.
- Authentication-results: sourceware.org; auth=none
- References: <1452277948-25292-1-git-send-email-lgustavo at codesourcery dot com> <alpine dot DEB dot 2 dot 00 dot 1601090245560 dot 5958 at tp dot orcam dot me dot uk> <5693CE90 dot 1060709 at codesourcery dot com> <5694F5BC dot 3050904 at redhat dot com> <5694FEB8 dot 10406 at codesourcery dot com> <56950952 dot 2030504 at redhat dot com> <56951F29 dot 7070000 at codesourcery dot com> <alpine dot DEB dot 2 dot 00 dot 1601121710020 dot 5958 at tp dot orcam dot me dot uk> <56B0A809 dot 6070101 at codesourcery dot com> <56B0BAEA dot 7 at redhat dot com> <56B0BBB4 dot 6050105 at redhat dot com> <alpine dot DEB dot 2 dot 00 dot 1602041949090 dot 15885 at tp dot orcam dot me dot uk>
- Reply-to: Luis Machado <lgustavo at codesourcery dot com>
On 02/04/2016 07:01 PM, Maciej W. Rozycki wrote:
On Tue, 2 Feb 2016, Pedro Alves wrote:
Did you try to trigger the assertion by loading a 32-bit MIPS binary
into gdb, and playing with "set mips abi n64/o64...", "set mipsfpu",
etc?
I think that adding a test to the testsuite that iterates through all
the possible combinations just to make sure gdb doesn't crash
would be great, and also show that the patch stands on its own
as well, irrespective of the bfd arch compatibility issues.
I was playing around with these settings.
TBC, I meant, the original patch that checked unsuitable ABI/ISA
combinations.
NB I can only see the use for these knobs to deal with two situations:
1. There's no executable and we want to connect to a live target for
minimal binary-only/disasembly-level debugging. We need to set the
endianness, ABI, ISA, etc. to match the target then (although arguably
at least the endianness should be supplied by the debug stub somehow;
we just don't have a way defined right now).
While trying reproducers out, i noticed this use case doesn't seem to
work properly under some conditions anymore. Whenever GDB doesn't find a
binary and sysroot is set to empty, it will not attempt to continue with
the remote session. It seems to just give up.
Sending packet: $qXfer:exec-file:read:6394:0,fff#60...Packet received:
lgdb.base/break
<- remote->to_xfer_partial (0xcb3a80, 27, 6394, 0xe38cc0, 0x0, 0x0,
0xfff, 0x98) = 1
remote:target_xfer_partial (27, 6394, 0xe38cc0, 0x0, 0x0, 4095) = 1,
152, bytes =
2f 6e 65 74 2f 62 75 69 6c 64 32 2d 6c 75 63 69 ...
-> remote->to_check_pending_interrupt (...)
<- remote->to_check_pending_interrupt (0xcb3a80)
-> remote->to_xfer_partial (...)
<- remote->to_xfer_partial (0xcb3a80, 27, 6394, 0xe38d58, 0x0, 0x98,
0xf67, 0x0) = 0
remote:target_xfer_partial (27, 6394, 0xe38d58, 0x0, 0x98, 3943) = 0, 0
<- remote->to_pid_to_exec_file (0xcb3a80, 25492) = gdb.base/break
target_close ()
gdb.base/break: No such file or directory.
(gdb) i r
The program has no registers now.
(gdb) kill
The program is not being run.
Otherwise gdbserver will transfer the file over from the remote end. But
i digress.
I can easily reproduce the internal error by simply loading a 32-bit
MIPS binary and flipping the abi to any of the 64-bit variants.
This doesn't seem to be terribly important as people interested in
playing with these setting will most likely know what they're doing.
The testcase causing an internal error seems to be even less important
and very unlikely to occur, but it always runs as part of the testsuite
and it is a bit of an annoyance.
GDB should not give an internal error or crash, obviously.
2. We have a buggy or outdated GDB executable which fails to determine the
right settings automatically. As it looks for example as recently as
last week I came across a problem where GDB failed to detect the
presence of the FPU under Linux for some reason. I had to forcefully
request `set mipsfpu double' to override the wrongly chosen setting of
`none', at which point accesses to the FPU worked as expected, so it
wasn't like the unit was inaccessible.
Obviously I need to debug #2, but overall I agree we ought to bail out
gracefully rather than crash if the manual settings lead to a nonsensical
configuration.
Therefore I went back to the original patch now. It obscures things a
bit I'm afraid from my point of view as it combines a syntactical change
(the addition of the `arch_is_incompatible' auxiliary variable) and a
semantical change (the addition of the `mips_isa == ISA_MIPS16' check), so
I'd like to see the two changes separated.
TBH I'm not convinced whether the auxiliary variable buys us anything
here -- it doesn't serve as documentation as we have an explanatory
comment here already, which BTW needs to be updated accordingly if the
condition is extended to cover an ISA incompatibility.
The naming could've been better. I went that route in the hopes that
future checks would just flip that boolean while keeping the conditional
block separate, otherwise we would have a bigger conditional block that
may not be as straightforward to parse.
As to which, and more importantly -- there is no actual architectural
incompatibility between the n64 (or n32) ABI and the MIPS16 instruction
set; there are 64-bit MIPS processors in existence which implement the
MIPS16 ISA as well, e.g. the NEC VR4111, and the ISA itself includes
64-bit instructions on such a processor. So the MIPS16 ISA is really
agnostic to the ABI, just as is the regular MIPS ISA or the microMIPS ISA.
Therefore any such fix needs to go elsewhere I'm afraid -- we probably do
something outright silly for the ISA_MIPS16 setting.
Fair enough. Do you have a suggestion on where that fix should go to?
The culprit seems to be the mix of an arch selection that gives us
64-bit cooked registers (due to mips_abi_regsize) and an ISA that gives
us 32-bit registers (due to mips_isa_regsize). With that combination,
mips_pseudo_register_read will fail in a fatal way, as well as
mips_pseudo_register_write if we ever manage to go past the reading step.
Luis