On Wed, May 05, 2021 at 03:11:18PM -0700, Andy Lutomirski wrote:
> Since I'm not holding my breath, please at least keep in mind that
> anything you do here is merely a heuristic, cannot be fully correct,
> and then whenever gdb determines that a thread group or a thread is
> "32-bit", gdb is actually deciding to operate in a degraded mode for
> that task, is not accurately representing the task state, and is at
> risk of crashing, malfunctioning, or crashing the inferior due to its
> incorrect assumptions. If you have ever attached gdb to QEMU's
> gdbserver and tried to debug the early boot process of a 64-bit Linux
> kernel, you may have encountered this class of bugs. gdb works very,
> very poorly for this use case.
So we were talking about this with toolchain folks today and they gave
me this example:
Imagine you've stopped the target this way:
<insn><-- stopped here
<insn>
<mode changing insn>
<insn>
<insn>
...
now, if you dump rIP and say, rIP + the 10 following insns at the place
you've stopped it, gdb cannot know that 2 insns further into the stream
a
<mode changing insn>
is coming and it should change the disassembly of the insns after that
<mode changing insn> to the new mode. Unless it goes and inspects all
further instructions and disassembles them and analyzes the flow...
So what you can do is
(gdb) set arch ...
at the <mode changing insn> to the mode you're changing to.
Dunno, maybe I'm missing something but this sounds like without user
help gdb can only assume things.
Good night and good luck.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
