* [Qemu-devel] [Bug] qemu-sparc64 broken
@ 2013-09-05 20:35 Stefan Weil
2013-09-05 21:32 ` Peter Maydell
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Weil @ 2013-09-05 20:35 UTC (permalink / raw)
To: qemu-devel
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--T 1 stefan root 1378329541 Jan 1 1970 block.c
It's obviously wrong. All other user emulations return the correct result:
$ busybox ls -l block.c
-rw-r--r-- 1 stefan stefan 131462 Sep 3 21:13 block.c
In a first analysis of this, I noticed that it is impossible to run
qemu-sparc64
under gdb (raised fatal signal). I was also surprised to see that
target_stat64
is unused.
Regards,
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [Bug] qemu-sparc64 broken
2013-09-05 20:35 [Qemu-devel] [Bug] qemu-sparc64 broken Stefan Weil
@ 2013-09-05 21:32 ` Peter Maydell
2013-09-06 4:53 ` Stefan Weil
0 siblings, 1 reply; 6+ messages in thread
From: Peter Maydell @ 2013-09-05 21:32 UTC (permalink / raw)
To: Stefan Weil; +Cc: qemu-devel
On 5 September 2013 21:35, Stefan Weil <sw@weilnetz.de> 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--T 1 stefan root 1378329541 Jan 1 1970 block.c
>
> It's obviously wrong. All other user emulations return the correct result:
SPARC linux-user emulation has been pretty badly broken
and obviously unused (except probably for being able to
run gcc test suite code) for some time (if it ever worked at all);
I fixed a pretty obvious problem in commit 82f05b69e6
which meant bash couldn't run any programs, for instance.
> $ busybox ls -l block.c
> -rw-r--r-- 1 stefan stefan 131462 Sep 3 21:13 block.c
Try checking the target_stat and target_stat64 struct
definitions in linux-user/syscall_defs.h against the kernel's
versions; there's probably a mismatch.
http://lxr.linux.no/#linux+v3.11/arch/sparc/include/uapi/asm/stat.h#L8
The most obvious error is that st_nlink should be a short,
not an int. One of the others must be wrong too, though,
because alignment padding would cancel that out. You
need to chase typedefs (and watch out for possible
arch-specific overrides of generic type choices)...
> 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 that it had a tendency to do lots
of (presumably safely handled) segfaulting while running;
didn't look at why this happens.
> I was also surprised to see that
> target_stat64 is unused.
sparc64 provides a stat64 syscall (probably for backward
compatibility), but any sensibly compiled libc should just
use stat, since with 64 bit longs the fields are all sensible
sizes anyway.
-- PMM
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [Bug] qemu-sparc64 broken
2013-09-05 21:32 ` Peter Maydell
@ 2013-09-06 4:53 ` Stefan Weil
2013-09-06 15:12 ` Richard Henderson
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Weil @ 2013-09-06 4:53 UTC (permalink / raw)
To: Peter Maydell; +Cc: qemu-devel
Am 05.09.2013 23:32, schrieb Peter Maydell:
> On 5 September 2013 21:35, Stefan Weil <sw@weilnetz.de> 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 that it had a tendency to do lots
> of (presumably safely handled) segfaulting while running;
> didn't look at why this happens.
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.
Now I can debug. I'll send a patch when it's fixed.
Regards,
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [Bug] qemu-sparc64 broken
2013-09-06 4:53 ` Stefan Weil
@ 2013-09-06 15:12 ` Richard Henderson
2013-09-06 15:15 ` Peter Maydell
0 siblings, 1 reply; 6+ messages in thread
From: Richard Henderson @ 2013-09-06 15:12 UTC (permalink / raw)
To: Stefan Weil; +Cc: Peter Maydell, qemu-devel
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 <sw@weilnetz.de> 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 that it had a tendency to do lots
>> of (presumably safely handled) segfaulting while running;
>> didn't look at why this happens.
>
> 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's not just sparc64.
That's changed page detection, for determining when to invalidate
translation blocks. For self-modifying code, and more.
r~
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [Bug] qemu-sparc64 broken
2013-09-06 15:12 ` Richard Henderson
@ 2013-09-06 15:15 ` Peter Maydell
2013-09-06 15:20 ` Richard Henderson
0 siblings, 1 reply; 6+ messages in thread
From: Peter Maydell @ 2013-09-06 15:15 UTC (permalink / raw)
To: Richard Henderson; +Cc: Stefan Weil, qemu-devel
On 6 September 2013 16:12, Richard Henderson <rth@twiddle.net> 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's not just sparc64.
>
> That's changed page detection, for determining when to invalidate
> translation blocks. For self-modifying code, and more.
Yeah, but in practice sparc64 does this a huge number of
times on simple binaries in a way that other linux-user
guests I looked at just don't. Presumably it's just that
gcc has for some reason put writable data next to code
for that target.
-- PMM
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [Bug] qemu-sparc64 broken
2013-09-06 15:15 ` Peter Maydell
@ 2013-09-06 15:20 ` Richard Henderson
0 siblings, 0 replies; 6+ messages in thread
From: Richard Henderson @ 2013-09-06 15:20 UTC (permalink / raw)
To: Peter Maydell; +Cc: Stefan Weil, qemu-devel
On 09/06/2013 08:15 AM, Peter Maydell wrote:
> On 6 September 2013 16:12, Richard Henderson <rth@twiddle.net> 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's not just sparc64.
>>
>> That's changed page detection, for determining when to invalidate
>> translation blocks. For self-modifying code, and more.
>
> Yeah, but in practice sparc64 does this a huge number of
> times on simple binaries in a way that other linux-user
> guests I looked at just don't. Presumably it's just that
> gcc has for some reason put writable data next to code
> for that target.
It's the (old?) PLT scheme for sparc -- it modifies code on linking.
If you use LD_BIND_NOW=1 it can help speed things up when debugging.
r~
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-09-06 15:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-05 20:35 [Qemu-devel] [Bug] qemu-sparc64 broken Stefan Weil
2013-09-05 21:32 ` Peter Maydell
2013-09-06 4:53 ` Stefan Weil
2013-09-06 15:12 ` Richard Henderson
2013-09-06 15:15 ` Peter Maydell
2013-09-06 15:20 ` Richard Henderson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).