This set of patches fixes bugs which were preventing the
Debian sparc64 /bin/bash from running:
 * the target_ucontext structure put the registers in the
   wrong place (missing alignment specifier, mostly)
 * the set_context and get_context traps weren't saving fp
   and i7, which meant that guest code that did a longjmp would
   crash shortly afterwards (SPARC64 uses these traps to
   implement setjmp/longjmp)
 * we were trying to stuff a 64-bit PC into a uint32_t in
   sigreturn, which caused a SEGV on return from a signal handler

Review very much desired in particular from anybody who understands
SPARC register windows and how we handle them in linux-user for
patch 2! The other patches are straightforward.

This patchset is sufficient that I can at least chroot into
a Debian sparc64 chroot and run basic commands like 'ls' from
the shell prompt (together with Giuseppe Musacchio's patch that
fixes the stack_t struct).

There are clearly a bunch of other bugs in sparc signal handling
(starting with the fact that rt_frame support is simply not
implemented, but there are also some XXX/FIXME comments about TSTATE
save/restore in set/get_context and about the FPU state in the signal
frame code). There's also a Coverity issue about accessing off the
end of the sregs[] array in the target_mc_fpu struct -- the error is
actually harmless (we're accessing into the space in the union for
dregs[16..31] which is what we want to be doing) but I'll probably
put together a patch to make Coverity happier.

thanks
-- PMM

Peter Maydell (3):
  linux-user/sparc: Fix errors in target_ucontext structures
  linux-user/sparc: Correct set/get_context handling of fp and i7
  linux-user/sparc: Don't zero high half of PC, NPC, PSR in sigreturn

 linux-user/sparc/signal.c | 62 ++++++++++++++++++++-------------------
 1 file changed, 32 insertions(+), 30 deletions(-)

-- 
2.20.1

On 05/11/2020 21:23, Peter Maydell wrote:

> This set of patches fixes bugs which were preventing the
> Debian sparc64 /bin/bash from running:
>   * the target_ucontext structure put the registers in the
>     wrong place (missing alignment specifier, mostly)
>   * the set_context and get_context traps weren't saving fp
>     and i7, which meant that guest code that did a longjmp would
>     crash shortly afterwards (SPARC64 uses these traps to
>     implement setjmp/longjmp)
>   * we were trying to stuff a 64-bit PC into a uint32_t in
>     sigreturn, which caused a SEGV on return from a signal handler
> 
> Review very much desired in particular from anybody who understands
> SPARC register windows and how we handle them in linux-user for
> patch 2! The other patches are straightforward.
> 
> This patchset is sufficient that I can at least chroot into
> a Debian sparc64 chroot and run basic commands like 'ls' from
> the shell prompt (together with Giuseppe Musacchio's patch that
> fixes the stack_t struct).
> 
> There are clearly a bunch of other bugs in sparc signal handling
> (starting with the fact that rt_frame support is simply not
> implemented, but there are also some XXX/FIXME comments about TSTATE
> save/restore in set/get_context and about the FPU state in the signal
> frame code). There's also a Coverity issue about accessing off the
> end of the sregs[] array in the target_mc_fpu struct -- the error is
> actually harmless (we're accessing into the space in the union for
> dregs[16..31] which is what we want to be doing) but I'll probably
> put together a patch to make Coverity happier.

Thanks Peter! This has been broken for a very long time indeed. Once this is merged I 
should probably look at getting a test environment set up.


ATB,

Mark.

Le 10/11/2020 à 13:56, Mark Cave-Ayland a écrit :
> On 05/11/2020 21:23, Peter Maydell wrote:
> 
>> This set of patches fixes bugs which were preventing the
>> Debian sparc64 /bin/bash from running:
>>   * the target_ucontext structure put the registers in the
>>     wrong place (missing alignment specifier, mostly)
>>   * the set_context and get_context traps weren't saving fp
>>     and i7, which meant that guest code that did a longjmp would
>>     crash shortly afterwards (SPARC64 uses these traps to
>>     implement setjmp/longjmp)
>>   * we were trying to stuff a 64-bit PC into a uint32_t in
>>     sigreturn, which caused a SEGV on return from a signal handler
>>
>> Review very much desired in particular from anybody who understands
>> SPARC register windows and how we handle them in linux-user for
>> patch 2! The other patches are straightforward.
>>
>> This patchset is sufficient that I can at least chroot into
>> a Debian sparc64 chroot and run basic commands like 'ls' from
>> the shell prompt (together with Giuseppe Musacchio's patch that
>> fixes the stack_t struct).
>>
>> There are clearly a bunch of other bugs in sparc signal handling
>> (starting with the fact that rt_frame support is simply not
>> implemented, but there are also some XXX/FIXME comments about TSTATE
>> save/restore in set/get_context and about the FPU state in the signal
>> frame code). There's also a Coverity issue about accessing off the
>> end of the sregs[] array in the target_mc_fpu struct -- the error is
>> actually harmless (we're accessing into the space in the union for
>> dregs[16..31] which is what we want to be doing) but I'll probably
>> put together a patch to make Coverity happier.
> 
> Thanks Peter! This has been broken for a very long time indeed. Once
> this is merged I should probably look at getting a test environment set up.

+1

With these patches,

on sparc, debootstrap (wheezy) has some issues but after some hacks
around the packages I've been able to build and run LTP.

on sparc64, debootstrap (sid) seems to work well but after that there
are some issues with apt (URI error)

Thanks,
Laurent