Saving to 32 bits of GPRs in signal context

[Steve Munroe]

Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote on 05/29/2007
04:44:15 PM:

>
> > But unless you take the time to write it up like a full ABI change you
are
> > never sure that it IS compatible. And any change to the size/shape of
> > ucontext_t is an ABI change.
> >
> > Also if you want to debug this code (see long long variables correctly
from
> > GDB or even see the upper 32-bits of GPRs) you will need an ABI change
so
> > that GDB/DWARF knows what to do.
>
> I personally don't care about gdb seeing those or anything like that,
> those would be strictly local asm optimisations, at least that's my
> point of view on the matter.
>
Well others do. If gcc supports code gen for this they will expect GDB
support.

> I intend not to extend or change the shape of ucontext neither. I'll add
> the highregs after the ucontext32 on the compat signal frame, the only
> change/addition is the use of a pad field to point to it and maybe
> setting a flag that was previously unused and always 0 to indicate that
> it's there.
>
The pad field may be occupied with data if the code was compiled on a older
distro and ucontext_t is misaligned (an odd Doubleword). So the pad field
is free for reuse onless you version the code to handle unalligned VMX
registers.

> Do you see any possible compatibility problem there ? Do you know of any
> piece of software that makes hard assumptions on the shape and size of a
> complete signal frame (not just the ucontext part of it) ?
>

The signal frame can change, as long as the relative offset and size of the
ucontext_t is unchanged.