We translate gUSA regions atomically in a parallel context.
But in a serial context a gUSA region may be interrupted.
In that case, restart the region as the kernel would.
Signed-off-by: Richard Henderson <rth@twiddle.net>
---
linux-user/signal.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 3d18d1b..a537778 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -3471,6 +3471,25 @@ static abi_ulong get_sigframe(struct target_sigaction *ka,
return (sp - frame_size) & -8ul;
}
+/* Notice when we're in the middle of a gUSA region and reset.
+ Note that this will only occur for !parallel_cpus, as we will
+ translate such sequences differently in a parallel context. */
+static void unwind_gusa(CPUSH4State *regs)
+{
+ /* If the stack pointer is sufficiently negative ... */
+ if ((regs->gregs[15] & 0xc0000000u) == 0xc0000000u
+ /* ... and we haven't completed the sequence ... */
+ && regs->pc < regs->gregs[0]) {
+ /* Reset the PC to before the gUSA region, as computed from
+ R0 = region end, SP = -(region size), plus one more insn
+ that actually sets SP to the region size. */
+ regs->pc = regs->gregs[0] + regs->gregs[15] - 2;
+
+ /* Reset the SP to the saved version in R1. */
+ regs->gregs[15] = regs->gregs[1];
+ }
+}
+
static void setup_sigcontext(struct target_sigcontext *sc,
CPUSH4State *regs, unsigned long mask)
{
@@ -3534,6 +3553,8 @@ static void setup_frame(int sig, struct target_sigaction *ka,
abi_ulong frame_addr;
int i;
+ unwind_gusa(regs);
+
frame_addr = get_sigframe(ka, regs->gregs[15], sizeof(*frame));
trace_user_setup_frame(regs, frame_addr);
if (!lock_user_struct(VERIFY_WRITE, frame, frame_addr, 0)) {
@@ -3583,6 +3604,8 @@ static void setup_rt_frame(int sig, struct target_sigaction *ka,
abi_ulong frame_addr;
int i;
+ unwind_gusa(regs);
+
frame_addr = get_sigframe(ka, regs->gregs[15], sizeof(*frame));
trace_user_setup_rt_frame(regs, frame_addr);
if (!lock_user_struct(VERIFY_WRITE, frame, frame_addr, 0)) {
--
2.9.4
On 07/07/2017 04:20 AM, Richard Henderson wrote: > We translate gUSA regions atomically in a parallel context. > But in a serial context a gUSA region may be interrupted. > In that case, restart the region as the kernel would. This patch is still causing random segfaults, unfortunately: Setting up dpkg (1.18.24+b1) ... Setting up perl-base (5.24.1-5) ... Setting up grep (2.27-2) ... Setting up debconf (1.5.62) ... Setting up tzdata (2017b-2) ... Current default time zone: 'Etc/UTC' Local time is now: Fri Jul 7 07:17:20 UTC 2017. Universal Time is now: Fri Jul 7 07:17:20 UTC 2017. Run 'dpkg-reconfigure tzdata' if you wish to change it. qemu: uncaught target signal 11 (Segmentation fault) - core dumped dpkg: error processing package tzdata (--configure): subprocess installed post-installation script was killed by signal (Segmentation fault) Setting up gzip (1.6-5) ... Setting up dash (0.5.8-2.4) ... Setting up init-system-helpers (1.48) ... Setting up libpam0g:sh4 (1.1.8-3.6) ... Setting up libpam-modules-bin (1.1.8-3.6) ... Setting up bash (4.4-5) ... Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 07/06/2017 09:25 PM, John Paul Adrian Glaubitz wrote: > On 07/07/2017 04:20 AM, Richard Henderson wrote: >> We translate gUSA regions atomically in a parallel context. >> But in a serial context a gUSA region may be interrupted. >> In that case, restart the region as the kernel would. > > This patch is still causing random segfaults, unfortunately: > > Setting up dpkg (1.18.24+b1) ... > Setting up perl-base (5.24.1-5) ... > Setting up grep (2.27-2) ... > Setting up debconf (1.5.62) ... > Setting up tzdata (2017b-2) ... > > Current default time zone: 'Etc/UTC' > Local time is now: Fri Jul 7 07:17:20 UTC 2017. > Universal Time is now: Fri Jul 7 07:17:20 UTC 2017. > Run 'dpkg-reconfigure tzdata' if you wish to change it. > > qemu: uncaught target signal 11 (Segmentation fault) - core dumped > dpkg: error processing package tzdata (--configure): > subprocess installed post-installation script was killed by signal (Segmentation fault) > Setting up gzip (1.6-5) ... > Setting up dash (0.5.8-2.4) ... > Setting up init-system-helpers (1.48) ... > Setting up libpam0g:sh4 (1.1.8-3.6) ... > Setting up libpam-modules-bin (1.1.8-3.6) ... > Setting up bash (4.4-5) ... How do I reproduce this from the filesystem image you linked earlier? r~
On 07/07/2017 10:20 AM, Richard Henderson wrote:
> How do I reproduce this from the filesystem image you linked earlier?
So, the problem happens in the tzdata package when it's being configured:
(sid-sh4-sbuild)root@nofan:/# dpkg-reconfigure tzdata
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = "en_US.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.)
debconf: falling back to frontend: Readline
Configuring tzdata
------------------
Please select the geographic area in which you live. Subsequent configuration questions will narrow this down by
presenting a list of cities, representing the time zones in which they are located.
1. Africa 3. Antarctica 5. Arctic 7. Atlantic 9. Indian 11. SystemV 13. Etc
2. America 4. Australia 6. Asia 8. Europe 10. Pacific 12. US
Geographic area: 8
Please select the city or region corresponding to your time zone.
1. Amsterdam 10. Bucharest 19. Isle_of_Man 28. Luxembourg 37. Paris 46. Simferopol 55. Vaduz
2. Andorra 11. Budapest 20. Istanbul 29. Madrid 38. Podgorica 47. Skopje 56. Vatican
3. Astrakhan 12. Busingen 21. Jersey 30. Malta 39. Prague 48. Sofia 57. Vienna
4. Athens 13. Chisinau 22. Kaliningrad 31. Mariehamn 40. Riga 49. Stockholm 58. Vilnius
5. Belfast 14. Copenhagen 23. Kiev 32. Minsk 41. Rome 50. Tallinn 59. Volgograd
6. Belgrade 15. Dublin 24. Kirov 33. Monaco 42. Samara 51. Tirane 60. Warsaw
7. Berlin 16. Gibraltar 25. Lisbon 34. Moscow 43. San_Marino 52. Tiraspol 61. Zagreb
8. Bratislava 17. Guernsey 26. Ljubljana 35. Nicosia 44. Sarajevo 53. Ulyanovsk 62. Zaporozhye
9. Brussels 18. Helsinki 27. London 36. Oslo 45. Saratov 54. Uzhgorod 63. Zurich
Time zone: 7
Current default time zone: 'Europe/Berlin'
Local time is now: Fri Jul 7 10:26:31 CEST 2017.
Universal Time is now: Fri Jul 7 08:26:31 UTC 2017.
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
(sid-sh4-sbuild)root@nofan:/#
The scripts which are run here can be found as /var/lib/dpkg/info/tzdata.{config,postinst). I don't know
yet which command in particular triggers the crash.
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 07/07/2017 10:30 AM, John Paul Adrian Glaubitz wrote:
> The scripts which are run here can be found as /var/lib/dpkg/info/tzdata.{config,postinst).
> I don't know yet which command in particular triggers the crash.
Interesting. It crashes for me immediately after resizing the terminal window with:
(sid-sh4-sbuild)root@nofan:/# Unhandled trap: 0x180
pc=0xf6ffe9fa sr=0x00000101 pr=0x004a73c2 fpscr=0x00080000
spc=0x00000000 ssr=0x00000000 gbr=0xf6646470 vbr=0x00000000
sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6ffea14 fpul=0x00000000
r0=0xfffffffc r1=0xf6ffea1c r2=0x00000000 r3=0x00000134
r4=0x00000001 r5=0xf6ffeac0 r6=0x00000000 r7=0x00000000
r8=0x00000000 r9=0x0041a050 r10=0xf677e4b8 r11=0xf6ffea40
r12=0xf677ec54 r13=0x00000000 r14=0x0041a0a4 r15=0xf6ffea1c
r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000
r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000
root@nofan:~>
I did not enter any commands. Just chrooting into the chroot, the resizing the
terminal window was enough.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 07/06/2017 10:35 PM, John Paul Adrian Glaubitz wrote:
> On 07/07/2017 10:30 AM, John Paul Adrian Glaubitz wrote:
>> The scripts which are run here can be found as /var/lib/dpkg/info/tzdata.{config,postinst).
>> I don't know yet which command in particular triggers the crash.
> Interesting. It crashes for me immediately after resizing the terminal window with:
>
> (sid-sh4-sbuild)root@nofan:/# Unhandled trap: 0x180
> pc=0xf6ffe9fa sr=0x00000101 pr=0x004a73c2 fpscr=0x00080000
> spc=0x00000000 ssr=0x00000000 gbr=0xf6646470 vbr=0x00000000
> sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6ffea14 fpul=0x00000000
> r0=0xfffffffc r1=0xf6ffea1c r2=0x00000000 r3=0x00000134
> r4=0x00000001 r5=0xf6ffeac0 r6=0x00000000 r7=0x00000000
> r8=0x00000000 r9=0x0041a050 r10=0xf677e4b8 r11=0xf6ffea40
> r12=0xf677ec54 r13=0x00000000 r14=0x0041a0a4 r15=0xf6ffea1c
> r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000
> r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000
> root@nofan:~>
>
> I did not enter any commands. Just chrooting into the chroot, the resizing the
> terminal window was enough.
Thanks for the hint. I've got it now.
The problem is that sh4-linux-user does not limit the page mappings in the same
way that the sh4 kernel does. So we begin the program with the stack mapped at
0xf7xxxxxx, which matches our normal check of 0xc0000000.
I think a more restricted check of -128 -- the most negative value that can be
placed by mov #imm,sp -- will work and is more appropriate. Indeed, I assume
that the only reason the kernel doesn't perform the check that was is having to
do it all in sh assembly with minimal free registers.
r~
Just as a heads-up: The current set of patches as they are present in the tgt-sh4 branch on git://github.com/rth7680/qemu.git are a HUGE improvement for qemu-sh4 user mode. Several packages which previously crashed during build or use can now be used properly! So, I hope to see this series merged upstream soon! Thanks a lot! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Thu, Jul 13, 2017 at 11:09:08AM +0200, John Paul Adrian Glaubitz wrote:
> Just as a heads-up: The current set of patches as they are present in
> the tgt-sh4 branch on git://github.com/rth7680/qemu.git are a HUGE
> improvement for qemu-sh4 user mode. Several packages which previously
> crashed during build or use can now be used properly!
The only thing that still doesn't work is GHC, unfortunately:
(sid-sh4-sbuild)root@nofan:/# ghc Main.hs
/bin/bash: warning: setlocale: LC_ALL: cannot change locale
(en_US.UTF-8)
[1 of 1] Compiling Main ( Main.hs, Main.o )
^C
(sid-sh4-sbuild)root@nofan:/# ghc Main.hs
/bin/bash: warning: setlocale: LC_ALL: cannot change locale
(en_US.UTF-8)
[1 of 1] Compiling Main ( Main.hs, Main.o )
^C
(sid-sh4-sbuild)root@nofan:/# ghc Main.hs
/bin/bash: warning: setlocale: LC_ALL: cannot change locale
(en_US.UTF-8)
[1 of 1] Compiling Main ( Main.hs, Main.o )
^C
(sid-sh4-sbuild)root@nofan:/# ghc Main.hs
/bin/bash: warning: setlocale: LC_ALL: cannot change locale
(en_US.UTF-8)
ghc: internal error: scavenge_static: strange closure 8
(GHC version 8.0.1 for sh4_unknown_linux)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
(sid-sh4-sbuild)root@nofan:/#
It either hangs, so I had to use "Ctrl+C" or it segfaulted.
Sometimes it would crash with:
(sid-sh4-sbuild)root@nofan:/# ghc Main.hs
/bin/bash: warning: setlocale: LC_ALL: cannot change locale
(en_US.UTF-8)
Unhandled trap: 0x180
pc=0x07019782 sr=0x00000000 pr=0x0668c52c fpscr=0x00080000
spc=0x00000000 ssr=0x00000000 gbr=0x7f5ae680 vbr=0x00000000
sgr=0x00000000 dbr=0x00000000 delayed_pc=0x0668c52c fpul=0x05f7595c
r0=0x07019780 r1=0x7d9f90d8 r2=0x00019780 r3=0x00009780
r4=0x00000001 r5=0x0000001e r6=0x70000000 r7=0x00000080
r8=0x00000001 r9=0x00000000 r10=0x7f5ae694 r11=0x00000000
r12=0x07099840 r13=0x7f4fe000 r14=0x7ffff4cc r15=0x7ffff4c8
r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000
r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000
(sid-sh4-sbuild)root@nofan:/#
Source file is available here [1]. In order to be able to install,
you need to bind-mount /proc into the chroot first:
mount -o bind /proc /path/to/sid-sh4-sbuild/proc/
Adrian
> [1] https://people.debian.org/~glaubitz/Main.hs
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 07/13/2017 12:56 AM, John Paul Adrian Glaubitz wrote: > It either hangs, so I had to use "Ctrl+C" or it segfaulted. > > Sometimes it would crash with: > > (sid-sh4-sbuild)root@nofan:/# ghc Main.hs > /bin/bash: warning: setlocale: LC_ALL: cannot change locale > (en_US.UTF-8) > Unhandled trap: 0x180 > pc=0x07019782 sr=0x00000000 pr=0x0668c52c fpscr=0x00080000 > spc=0x00000000 ssr=0x00000000 gbr=0x7f5ae680 vbr=0x00000000 > sgr=0x00000000 dbr=0x00000000 delayed_pc=0x0668c52c fpul=0x05f7595c > r0=0x07019780 r1=0x7d9f90d8 r2=0x00019780 r3=0x00009780 > r4=0x00000001 r5=0x0000001e r6=0x70000000 r7=0x00000080 > r8=0x00000001 r9=0x00000000 r10=0x7f5ae694 r11=0x00000000 > r12=0x07099840 r13=0x7f4fe000 r14=0x7ffff4cc r15=0x7ffff4c8 > r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 > r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 > (sid-sh4-sbuild)root@nofan:/# > > Source file is available here [1]. In order to be able to install, > you need to bind-mount /proc into the chroot first: > > mount -o bind /proc /path/to/sid-sh4-sbuild/proc/ > > Adrian > >> [1] https://people.debian.org/~glaubitz/Main.hs I can reproduce this non-reproducible behaviour. Unfortunately with something as complex as ghc this doesn't help much. I hope you can find something smaller that produces a similar problem... r~
On 07/13/2017 11:37 PM, Richard Henderson wrote: > Unfortunately with something as complex as ghc this doesn't help much. > I hope you can find something smaller that produces a similar problem... GHC is truly a complex matter. It's in fact the package that causes most trouble on qemu-user, both on m68k and sh4. Although it works fine on qemu-user for ARM. I will try to reduce the test case. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Le 07/07/2017 à 04:20, Richard Henderson a écrit :
> We translate gUSA regions atomically in a parallel context.
> But in a serial context a gUSA region may be interrupted.
> In that case, restart the region as the kernel would.
>
> Signed-off-by: Richard Henderson <rth@twiddle.net>
> ---
> linux-user/signal.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/linux-user/signal.c b/linux-user/signal.c
> index 3d18d1b..a537778 100644
> --- a/linux-user/signal.c
> +++ b/linux-user/signal.c
> @@ -3471,6 +3471,25 @@ static abi_ulong get_sigframe(struct target_sigaction *ka,
> return (sp - frame_size) & -8ul;
> }
>
> +/* Notice when we're in the middle of a gUSA region and reset.
> + Note that this will only occur for !parallel_cpus, as we will
> + translate such sequences differently in a parallel context. */
> +static void unwind_gusa(CPUSH4State *regs)
> +{
> + /* If the stack pointer is sufficiently negative ... */
> + if ((regs->gregs[15] & 0xc0000000u) == 0xc0000000u
> + /* ... and we haven't completed the sequence ... */
> + && regs->pc < regs->gregs[0]) {
> + /* Reset the PC to before the gUSA region, as computed from
> + R0 = region end, SP = -(region size), plus one more insn
> + that actually sets SP to the region size. */
> + regs->pc = regs->gregs[0] + regs->gregs[15] - 2;
> +
> + /* Reset the SP to the saved version in R1. */
> + regs->gregs[15] = regs->gregs[1];
> + }
> +}
> +
> static void setup_sigcontext(struct target_sigcontext *sc,
> CPUSH4State *regs, unsigned long mask)
> {
> @@ -3534,6 +3553,8 @@ static void setup_frame(int sig, struct target_sigaction *ka,
> abi_ulong frame_addr;
> int i;
>
> + unwind_gusa(regs);
> +
> frame_addr = get_sigframe(ka, regs->gregs[15], sizeof(*frame));
I think unwind_gusa() should be moved after the get_sigfram() (in both
cases), because r15 can be updated and the sigframe base lost.
@@ -3551,9 +3552,8 @@ static void setup_frame(int sig, struct
target_sigaction *
ka,
abi_ulong frame_addr;
int i;
- unwind_gusa(regs);
-
frame_addr = get_sigframe(ka, regs->gregs[15], sizeof(*frame));
+ unwind_gusa(regs);
trace_user_setup_frame(regs, frame_addr);
if (!lock_user_struct(VERIFY_WRITE, frame, frame_addr, 0)) {
goto give_sigsegv;
@@ -3602,9 +3602,8 @@ static void setup_rt_frame(int sig, struct
target_sigaction *ka,
abi_ulong frame_addr;
int i;
- unwind_gusa(regs);
-
frame_addr = get_sigframe(ka, regs->gregs[15], sizeof(*frame));
+ unwind_gusa(regs);
trace_user_setup_rt_frame(regs, frame_addr);
if (!lock_user_struct(VERIFY_WRITE, frame, frame_addr, 0)) {
goto give_sigsegv;
Laurent
Le 07/07/2017 à 11:05, Laurent Vivier a écrit :
> Le 07/07/2017 à 04:20, Richard Henderson a écrit :
>> We translate gUSA regions atomically in a parallel context.
>> But in a serial context a gUSA region may be interrupted.
>> In that case, restart the region as the kernel would.
>>
>> Signed-off-by: Richard Henderson <rth@twiddle.net>
>> ---
>> linux-user/signal.c | 23 +++++++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/linux-user/signal.c b/linux-user/signal.c
>> index 3d18d1b..a537778 100644
>> --- a/linux-user/signal.c
>> +++ b/linux-user/signal.c
>> @@ -3471,6 +3471,25 @@ static abi_ulong get_sigframe(struct target_sigaction *ka,
>> return (sp - frame_size) & -8ul;
>> }
>>
>> +/* Notice when we're in the middle of a gUSA region and reset.
>> + Note that this will only occur for !parallel_cpus, as we will
>> + translate such sequences differently in a parallel context. */
>> +static void unwind_gusa(CPUSH4State *regs)
>> +{
>> + /* If the stack pointer is sufficiently negative ... */
>> + if ((regs->gregs[15] & 0xc0000000u) == 0xc0000000u
>> + /* ... and we haven't completed the sequence ... */
>> + && regs->pc < regs->gregs[0]) {
>> + /* Reset the PC to before the gUSA region, as computed from
>> + R0 = region end, SP = -(region size), plus one more insn
>> + that actually sets SP to the region size. */
>> + regs->pc = regs->gregs[0] + regs->gregs[15] - 2;
>> +
>> + /* Reset the SP to the saved version in R1. */
>> + regs->gregs[15] = regs->gregs[1];
>> + }
>> +}
>> +
>> static void setup_sigcontext(struct target_sigcontext *sc,
>> CPUSH4State *regs, unsigned long mask)
>> {
>> @@ -3534,6 +3553,8 @@ static void setup_frame(int sig, struct target_sigaction *ka,
>> abi_ulong frame_addr;
>> int i;
>>
>> + unwind_gusa(regs);
>> +
>> frame_addr = get_sigframe(ka, regs->gregs[15], sizeof(*frame));
>
> I think unwind_gusa() should be moved after the get_sigfram() (in both
> cases), because r15 can be updated and the sigframe base lost.
>
No, it's stupid, r15 is negative
Laurent
On 07/07/2017 11:05 AM, Laurent Vivier wrote:> I think unwind_gusa() should be moved after the get_sigfram() (in both> cases), because r15 can be updated and the sigframe base lost. Tried the change. "dpkg-reconfigure tzdata" now crashes differently: Current default time zone: 'Europe/Berlin' Local time is now: Fri Jul 7 11:11:52 CEST 2017. Universal Time is now: Fri Jul 7 09:11:52 UTC 2017. Unhandled trap: 0x180 pc=0xf6fff39a sr=0x00000100 pr=0x00512c28 fpscr=0x00080004 spc=0x00000000 ssr=0x00000000 gbr=0xf6585470 vbr=0x00000000 sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6fff3ac fpul=0x00000002 r0=0xffffffe0 r1=0x00000470 r2=0x00afc048 r3=0x00000004 r4=0x0000000a r5=0x00bbdc18 r6=0x00000001 r7=0x00000001 r8=0x00bbdc18 r9=0x00bbdc18 r10=0x00000001 r11=0x0041728c r12=0x0000000a r13=0x0041744c r14=0x0058a384 r15=0x00000470 r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 (sid-sh4-sbuild)root@nofan:/# The crash on terminal resize is still present, too. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 2017-07-06 16:20, Richard Henderson wrote: > We translate gUSA regions atomically in a parallel context. > But in a serial context a gUSA region may be interrupted. > In that case, restart the region as the kernel would. > > Signed-off-by: Richard Henderson <rth@twiddle.net> > --- > linux-user/signal.c | 23 +++++++++++++++++++++++ > 1 file changed, 23 insertions(+) With my limited knowledge of linux-user: Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
© 2016 - 2025 Red Hat, Inc.