On 09/05/2013 09:53 PM, Stefan Weil wrote:
> Am 05.09.2013 23:32, schrieb Peter Maydell:
>> On 5 September 2013 21:35, Stefan Weil wrote:
>>> In a first analysis of this, I noticed that it is impossible to run
>>> qemu-sparc64
>>> under gdb (raised fatal signal).
>> You probably just need to let t
On 09/06/2013 08:15 AM, Peter Maydell wrote:
> On 6 September 2013 16:12, Richard Henderson wrote:
>> On 09/05/2013 09:53 PM, Stefan Weil wrote:
>>> After lots of SIGSEGV, the program indeed finishes successfully,
>>> so my report was wrong - SIGSEGV is not a fatal signal for sparc64.
>>> That's i
On 6 September 2013 16:12, Richard Henderson wrote:
> On 09/05/2013 09:53 PM, Stefan Weil wrote:
>> After lots of SIGSEGV, the program indeed finishes successfully,
>> so my report was wrong - SIGSEGV is not a fatal signal for sparc64.
>> That's interesting - thank you for this information.
>
> It
Am 05.09.2013 23:32, schrieb Peter Maydell:
> On 5 September 2013 21:35, Stefan Weil wrote:
>> In a first analysis of this, I noticed that it is impossible to run
>> qemu-sparc64
>> under gdb (raised fatal signal).
> You probably just need to let the signals go through to
> the target... I noticed
On 5 September 2013 21:35, Stefan Weil wrote:
> Here is the result of running Debian's busybox-static for sparc64:
>
> $ sparc64-linux-user/qemu-sparc64 /usr/gnemul/qemu-sparc64/bin/busybox
> ls -l block.c
> ?rwxr-x--T1 stefan root 1378329541 Jan 1 1970 block.c
>
> It's obviously wrong
Here is the result of running Debian's busybox-static for sparc64:
$ sparc64-linux-user/qemu-sparc64 /usr/gnemul/qemu-sparc64/bin/busybox
ls -l block.c
?rwxr-x--T1 stefan root 1378329541 Jan 1 1970 block.c
It's obviously wrong. All other user emulations return the correct result:
$ b
