Re: re-enabling debugging of 32 bit processes with 64 bit debugger

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

On Mon, 1 Jul 2019 at 10:06, Kamil Rytarowski <n54%gmx.com@localhost> wrote:
>
> On 01.07.2019 16:01, Christos Zoulas wrote:
> > In article <qfd1sp$9bj$1%serpens.de@localhost>,
> > Michael van Elst <mlelstv%serpens.de@localhost> wrote:
> >> christos%astron.com@localhost (Christos Zoulas) writes:
> >>
> >>> We can fill them completely with 0 as we pad with 0 the 32 bit
> >>> part of the 64 bit registers that does not exist in a 32 bit
> >>> process.
> >>
> >> The corefile pretends to be a 32bit file, so the register
> >> section should probably be similar to a coredump of a
> >> 32bit system.
> >>
> >> N.B. two registers were not zero padded, a temporary and the 'hi'
> >> register. So I don't think there is padding (or truncating)
> >> done.
> >
> > I have not looked at the core file, I was referring to what should be
> > returned by PT_GETREGS in the 64 bit tracer 32 bit tracee case.
> >
> > christos
> >
>
> From a debugger point of view, native struct reg, that is on the kernel
> side adapted (truncated registers) for 32bit tracee

Right, a 64-bit ptrace() interface must return 64-bit structures.  I'd
start with that, test it and see what breaks.

However, beyond that, the main thing is for all parties to play nice.
In general:
- when reading values the debugger is converting 64-bit raw values to
the 32-bit ISA
- when storing values the debugger should be writing to the full
64-bit ISA register
- and the kernel should kindly do the same thing
But wait, and this is where everyone gets to play nice.  There's
likely some obscure edge case where the kernel needs to leak a full
64-bit register value so that some feature works - perhaps h/w debug
registers, perhaps not.

Andrew