Bug in Qemu User Mode

[Dietmar Stölting]

Hi,
I make an interesting discovery.
My aim is to have a working qemu-i386 on Raspberry Pi.
After long searching in the dark what goes wrong with ANY Qemu version for User Mode until today,
I find the following: The bug must be in at least one function, that the program testclone
from the testpackage for i386 in linux-user-test-0.3 calls.
The wrong function is in the part, which enables more than one thread at the same time, NPTL.
Funny, how I find this out: All the programs from the tests in linux-user-test-0.3 I can now run succesfull with my new builded qemu-i386 for Raspi.
But the program testclone does not stop after it gives out all the right messages.
The program testclone stops on my Desktop computer with Debian Wheezy installed.
So, the error is not in the program testclone.
So I make a look, what is going on there with strace. With strace you get informations about all the values in the working program, here testclone.
I see, that the reason, why testclone not stops is in an infinite loop because of
while (waitpid(pid1, &status1, 0) != pid1);
while (waitpid(pid2, &status2, 0) != pid2);
at its end is never fullfilled.
This is the reason for the famous error message from Qemu User Mode

qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

stack1 = malloc(STACK_SIZE);
pid1 = clone(thread1_func, stack1 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, "hello1");

stack2 = malloc(STACK_SIZE);
pid2 = clone(thread2_func, stack2 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, "hello2");

The error happens early in the program testclone. Strace says, it is because no childprocess at all can be found. So, some basiccalculations in those four lines must be done wrong from Qemu.
I think, that the adressspace for each thread is calculated wrong, or overlapps.
Funny, it has nothing to do with the ARM processor. I get exact the same errormessages, when I run the program testclone on my desktopcompi i386 with a Wheezy in Qemu and then qemu-i386 testclone.
This is a good message, because it means it is an error, that belongs at least to the i386 family but I think, every processor in Qemu User Mode is involved, so until now NPTL does not work.
Today I make a hand by hand calculation with the source code from testclone and compare it with the values, that Qemu User Mode give. The handcalculated values should be the same which my
Desktop computer with Wheezy with tesclone produces, but who knows,
Dietmar

PS: I hope, that this is the right source code for testclone. Any help is welcome:-)!

Code: Select all
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <signal.h>
#include <unistd.h>
#include <inttypes.h>
#include <pthread.h>
#include <sys/wait.h>
#include <sched.h>

int thread1_func(void *arg)
{
    int i;
    char buf[512];

    for(i=0;i<10;i++) {
        snprintf(buf, sizeof(buf), "thread1: %d %s\n", i, (char *)arg);
       write(1, buf, strlen(buf));
        usleep(100 * 1000);
    }
    return 0;
}

int thread2_func(void *arg)
{
    int i;
    char buf[512];
    for(i=0;i<20;i++) {
        snprintf(buf, sizeof(buf), "thread2: %d %s\n", i, (char *)arg);
        write(1, buf, strlen(buf));
        usleep(120 * 1000);
    }
    return 0;
}

#define STACK_SIZE 16384

void test_clone(void)
{
    uint8_t *stack1, *stack2;
    int pid1, pid2, status1, status2;

    stack1 = malloc(STACK_SIZE);
    pid1 = clone(thread1_func, stack1 + STACK_SIZE,
                 CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, "hello1");

    stack2 = malloc(STACK_SIZE);
    pid2 = clone(thread2_func, stack2 + STACK_SIZE,
                CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, "hello2");

    while (waitpid(pid1, &status1, 0) != pid1);
    while (waitpid(pid2, &status2, 0) != pid2);
    printf("status1=0x%x\n", status1);
    printf("status2=0x%x\n", status2);
    printf("End of clone test.\n");
}

int main(int argc, char **argv)
{
    test_clone();
    return 0;
}
Posts: 210
Joined: 04 Sep 2011 17:43

[Dietmar Stölting (dietmar-stoelting)]

I just compiled the testclone new on debian Wheezy,
for to understand what is going on and name it clonemi.
Before I have always an endless loop on Raspberry Pi
because waitpid was never fullfilled.
So I commened the two waitpid lines out.
Also I enlarged the STACK_SIZE to 262144.
Enlarging of the stack does not help. But now the Raspberry Pi with
qemu-1386 -strace clonemi
showed the following output:

root@raspberrypi:/home/pi/raspidev# qemu-i386 clonemi
thread2: 0 hello2
thread1: 0 hello1
status1=0x80487ab
status2=0x42fd4788
End of clone test.

root@raspberrypi:/home/pi/raspidev# qemu-i386 -strace clonemi
1583 brk(NULL) = 0x0804a000
1583 uname(0x42fcb4ca) = 0
1583 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
1583 mmap2(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x43088000
1583 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory)
1583 open("/etc/ld.so.cache",O_RDONLY) = 3
1583 fstat64(3,0x42fcb184) = 0
1583 mmap2(NULL,7566,PROT_READ,MAP_PRIVATE,3,0) = 0x4308a000
1583 close(3) = 0
1583 open("/lib/libc.so.6",O_RDONLY) = 3
1583 read(3,0x42fcb2b8,512) = 512
1583 fstat64(3,0x42fcb1d8) = 0
1583 mmap2(NULL,1345848,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x4308c000
1583 mprotect(0x431ce000,4096,PROT_NONE) = 0
1583 mmap2(0x431cf000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x142) = 0x431cf000
1583 mmap2(0x431d2000,10552,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x431d2000
1583 close(3) = 0
1583 mmap2(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x431d5000
1583 set_thread_area(1123858048,1124618228,1125996224,1,0,1123858076) = 0
1583 mprotect(0x431cf000,8192,PROT_READ) = 0
1583 mprotect(0x43084000,4096,PROT_READ) = 0
1583 munmap(0x4308a000,7566) = 0
1583 mmap2(NULL,266240,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x431d6000
1583 clone(CLONE_VM|CLONE_FS|CLONE_FILES|0x11,child_stack=0x43215fe4,parent_tidptr=0x43076590,tls=0x08049a34,child_tidptr=0x42fcb788) = 1584
1583 mmap2(NULL,266240,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x43303000
1583 clone(CLONE_VM|CLONE_FS|CLONE_FILES|0x11,child_stack=0x43342fe4,parent_tidptr=0x43076590,tls=0x08049a34,child_tidptr=0x42fcb788) = 1585
1583 fstat64(1,0x42fcb09c) = 0
1583 mmap2(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x43344000
1583 write(1,0x43342ddc,18)thread2: 0 hello2
 = 18
1583 write(1,0x43215ddc,18)thread1: 0 hello1
 = 18
1583 nanosleep(1126260128,0,134514044,0,1809,1126260136)1583 nanosleep(1127493024,0,134514175,0,1809,1127493032)1583 write(1,0x43344000,18)status1=0x80487ab
 = 18
1583 write(1,0x43344000,19)status2=0x42fcb788
 = 19
1583 write(1,0x43344000,19)End of clone test.
 = 19
1583 exit_group(0)
root@raspberrypi:/home/pi/raspidev#

You can see, that
child_stack=0x43215fe4,parent_tidptr=0x43076590
is unequal.
Is this the mistake?

Nice to hear from you,
Dietmar

[Dietmar Stölting (dietmar-stoelting)]

I mean of course, that the tidptr from child and parent are different,

parent_tidptr=0x43076590 child_tidptr=0x42fcb788

Dietmar

[Dietmar Stölting (dietmar-stoelting)]

After studying the source code of testclone intensive,
I see only one possibility:
The implementation of the function [b]clone() [/b]in
Qemu User Mode must be wrong.
This would indeed affect any configuration,
means it is NOT CPU depending,
Dietmar

[Peter Maydell (pmaydell)]

Yes, threading does not work for i386 guests; this is a long-standing issue. (See also bug 739785.)

[Dietmar Stölting (dietmar-stoelting)]

Hi,
thanks for answer. Do you know, where the real problem in threading for i386 guests is?
Some kind of NPTL is implemented in Qemu and it could be necessary tested for host arm - guest arm
and also host i386 - guest arm with qemu-arm testclone in commandline.
I saw the attemps in past by David Woodhouse, Alexander Graf, Ulricht Hecht, Natan Froyd,
Mathieu Castet and even more to enable NPTL for i386 guest in qemu.
Why does not work :-),
Dietmar

[Dietmar Stölting (dietmar-stoelting)]

Hi,
I just make a test if my thoughts are right. On a Wheezy debian i386 I type in comandline
qemu-i386 -strace clonemi
(clonemi is the program testclone but with the endless loops in waitpid at its end put out.)
The result is exact like on Raspberry Pi with ARM 1176 processor.
So you can see, that the error belongs to the try of building TWO threads in the guest i386,
independ which host you have,
Dietmar

PS: Again the parent_tidptr and the child_tidptr are different in the SAME clone(),
but are identic to the values in the other thread with clone(). What does this mean?

root@didi2:/home/didi2# qemu-i386 -strace clonemi
12270 brk(NULL) = 0x0804a000
12270 uname(0x408007fa) = 0
12270 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
12270 mmap2(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x40821000
12270 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory)
12270 open("/etc/ld.so.cache",O_RDONLY) = 3
12270 fstat64(3,0x408004b4) = 0
12270 mmap2(NULL,78819,PROT_READ,MAP_PRIVATE,3,0) = 0x40823000
12270 close(3) = 0
12270 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
12270 open("/lib/i386-linux-gnu/i686/cmov/libc.so.6",O_RDONLY) = 3
12270 read(3,0x408005e8,512) = 512
12270 fstat64(3,0x40800508) = 0
12270 mmap2(NULL,1427832,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x40837000
12270 mprotect(0x4098d000,4096,PROT_NONE) = 0
12270 mmap2(0x4098e000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x156) = 0x4098e000
12270 mmap2(0x40991000,10616,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x40991000
12270 close(3) = 0
12270 mmap2(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x40994000
12270 set_thread_area(1082132912,1082253300,1083786944,1,0,1082132940) = 0
12270 mprotect(0x4098e000,8192,PROT_READ) = 0
12270 mprotect(0x4081d000,4096,PROT_READ) = 0
12270 munmap(0x40823000,78819) = 0
12270 mmap2(NULL,266240,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x40995000
12270 clone(CLONE_VM|CLONE_FS|CLONE_FILES|0x11,child_stack=0x409d4fe4,parent_tidptr=0x4080f590,tls=0x08049a34,child_tidptr=0x40800ab8) = 12271
12270 mmap2(NULL,266240,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x409d6000
12270 clone(CLONE_VM|CLONE_FS|CLONE_FILES|0x11,child_stack=0x40a15fe4,parent_tidptr=0x4080f590,tls=0x08049a34,child_tidptr=0x40800ab8) = 12272
12270 fstat64(1,0x408003b4) = 0
12270 write(1,0x409d4ddc,18)thread1: 0 hello1
12270 write(1,0x40a15ddc,18)thread2: 0 hello2
 = 18
12270 mmap2(NULL,4096,PROT_READ|PROT_WRITE,12270 nanosleep(1084050848,0,134514044,0,1809,1084050856) = 18
MAP_PRIVATE|MAP_ANONYMOUS,-1,0)12270 nanosleep(1084317088,0,134514175,0,1809,1084317096) = 0x40a17000
12270 write(1,0x40a17000,18)status1=0x80487ab
 = 18
12270 write(1,0x40a17000,19)status2=0x40800ab8
 = 19
12270 write(1,0x40a17000,19)End of clone test.
 = 19
12270 exit_group(0)
root@didi2:/home/didi2#

[Dietmar Stölting (dietmar-stoelting)]

I did some more tests:
In the newest version of Qemu Linaro I put in folder Linux-User
in the file syscall.c the following

    target_ldt_info->base_addr = tswapal(base_addr);
    target_ldt_info->limit = tswap32(limit);
    target_ldt_info->flags = tswap32(flags);
    unlock_user_struct(target_ldt_info, ptr, 1);
    return 0;
}
static inline void cpu_set_tls(CPUX86State *env, target_ulong newtls)
{
    do_set_thread_area(env, newtls);
    cpu_x86_load_seg(env, R_GS, env->segs[R_GS].selector);
}
#endif /* TARGET_I386 && TARGET_ABI32 */

#ifndef TARGET_ABI32
static abi_long do_arch_prctl(CPUX86State *env, int code, abi_ulong addr)
{
    abi_long ret = 0;
        pthread_attr_t attr;
#endif
        ts = g_malloc0(sizeof(TaskState));
        init_task_state(ts);
        /* we create a new CPU instance. */
        new_env = cpu_copy(env);
#if defined(TARGET_I386)
        new_env->idt.base = target_mmap(0, sizeof(uint64_t) * (env->idt.limit + 1),
                PROT_READ|PROT_WRITE,
                MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
        memcpy(g2h(new_env->idt.base), g2h(env->idt.base), sizeof(uint64_t) * (env->idt.limit + 1));
        new_env->gdt.base = target_mmap(0, sizeof(uint64_t) * TARGET_GDT_ENTRIES,
                PROT_READ|PROT_WRITE,
                MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
        memcpy(g2h(new_env->gdt.base), g2h(env->gdt.base), sizeof(uint64_t) * TARGET_GDT_ENTRIES);
#elif defined(TARGET_SPARC) || defined(TARGET_PPC)
        cpu_reset(ENV_GET_CPU(new_env));
#endif
        /* Init regs that differ from the parent. */
        cpu_clone_regs(new_env, newsp);
        new_env->opaque = ts;
        ts->bprm = parent_ts->bprm;

It is just as if the missed function cpu_set_tls(CPUX86State *env, target_ulong newtls) in folder cpu.h for i386 has moved to syscall.c:-).

Now I can play Quake2 with
qemu-i386 quake2

but the testclone program still not stops. May be, that there is something missed in #include<...>
in syscall.c, because now there is the function declaration for i386 for cpu_set_tls() there?
Or that simple a file is missed that is needed for the function clone(), espacelly for i386?
May be some of the flags are set always wrong in clone()?
WHY are there wrong adresses for the child process?
Is the reserved space for the child zero? Why has the child and the parent identical adresses in 2 different threads? With a wrong adress for the child, no threads are posible at all.
May be it is not so difficult to make it work,
but I am not so good in this:-)

Dietmar

[Dietmar Stölting (dietmar-stoelting)]

Hi,
with this new syscall.c content above things are going in the right direction:-).
I make a test with strace from the program testthread of the Qemu testsuite.
When I understand the result right,
threading works now with this new compiled qemu-i386.
The child and the parents tidptr NOW have the same number in one thread, and different but also same in other thread.
This means for the not working program testclone: The functioncall with its sets of parameters is just wrong there.
When you do a function call with those Flags as in testthread, threads can be builded with qemu-i386.
So, the error is in the wrong calling of the function clone(). This can be corrected. Please tell me your thoughts,
Dietmar

root@raspberrypi:/home/pi/raspidev# qemu-i386 -strace testthread
1583 brk(NULL) = 0x0804a000
1583 uname(0x4300d4ca) = 0
1583 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
1583 mmap2(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x4311c000
1583 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory)
1583 open("/etc/ld.so.cache",O_RDONLY) = 3
1583 fstat64(3,0x4300d184) = 0
1583 mmap2(NULL,41656,PROT_READ,MAP_PRIVATE,3,0) = 0x4311e000
1583 close(3) = 0
1583 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
1583 open("/lib/i386-linux-gnu/tls/i686/sse2/cmov/libpthread.so.0",O_RDONLY) = -1 errno=2 (No such file or directory)
1583 stat64("/lib/i386-linux-gnu/tls/i686/sse2/cmov",0x4300d1e8) = -1 errno=2 (No such file or directory)
1583 open("/lib/i386-linux-gnu/tls/i686/sse2/libpthread.so.0",O_RDONLY) = -1 errno=2 (No such file or directory)
1583 stat64("/lib/i386-linux-gnu/tls/i686/sse2",0x4300d1e8) = -1 errno=2 (No such file or directory)
1583 open("/lib/i386-linux-gnu/tls/i686/cmov/libpthread.so.0",O_RDONLY) = -1 errno=2 (No such file or directory)
1583 stat64("/lib/i386-linux-gnu/tls/i686/cmov",0x4300d1e8) = -1 errno=2 (No such file or directory)
1583 open("/lib/i386-linux-gnu/tls/i686/libpthread.so.0",O_RDONLY) = -1 errno=2 (No such file or directory)
1583 stat64("/lib/i386-linux-gnu/tls/i686",0x4300d1e8) = -1 errno=2 (No such file or directory)
1583 open("/lib/i386-linux-gnu/tls/sse2/cmov/libpthread.so.0",O_RDONLY) = -1 errno=2 (No such file or directory)
1583 stat64("/lib/i386-linux-gnu/tls/sse2/cmov",0x4300d1e8) = -1 errno=2 (No such file or directory)
1583 open("/lib/i386-linux-gnu/tls/sse2/libpthread.so.0",O_RDONLY) = -1 errno=2 (No such file or directory)
1583 stat64("/lib/i386-linux-gnu/tls/sse2",0x4300d1e8) = -1 errno=2 (No such file or directory)
1583 open("/lib/i386-linux-gnu/tls/cmov/libpthread.so.0",O_RDONLY) = -1 errno=2 (No such file or directory)
1583 stat64("/lib/i386-linux-gnu/tls/cmov",0x4300d1e8) = -1 errno=2 (No such file or directory)
1583 open("/lib/i386-linux-gnu/tls/libpthread.so.0",O_RDONLY) = -1 errno=2 (No such file or directory)
1583 stat64("/lib/i386-linux-gnu/tls",0x4300d1e8) = -1 errno=2 (No such file or directory)
1583 open("/lib/i386-linux-gnu/i686/sse2/cmov/libpthread.so.0",O_RDONLY) = -1 errno=2 (No such file or directory)
1583 stat64("/lib/i386-linux-gnu/i686/sse2/cmov",0x4300d1e8...

[Peter Maydell (pmaydell)]

On 14 August 2012 02:01, Dietmar Stölting <email address hidden> wrote:
> with this new syscall.c content above things are going in the right direction:-).
> I make a test with strace from the program testthread of the Qemu testsuite.
> When I understand the result right,
> threading works now with this new compiled qemu-i386.
> The child and the parents tidptr NOW have the same number in one thread, and different but also same in other thread.
> This means for the not working program testclone: The functioncall with its sets of parameters is just wrong there.
> When you do a function call with those Flags as in testthread, threads can be builded with qemu-i386.
> So, the error is in the wrong calling of the function clone(). This can be corrected. Please tell me your thoughts,

Yes, as I said, we know that threading does not work for i386 targets
(it is also
broken in more subtle ways for other targets). This is not going to get fixed
until it is investigated by somebody who has the time and expertise with both
i386 architecture and QEMU internals to produce a coherent fix which addresses
all the problems in this area. (See also my remarks in comment #47 of bug
739785.)

I'm sorry if that sounds a bit negative, but there is a reason this bug has
been unfixed for over a year -- it's not a trivial one to fix, and it's
not easy to evaluate whether a small patch is a component of the complete
correct solution without investing the time to think about the problem as
a whole.

-- PMM

[Dietmar Stölting (dietmar-stoelting)]

I just compare the source code for testthread.c and testclone.c.
The only difference I see is, HOW the function clone() is called.
In testthread via pthread_create()
in testclone via clone() direct.
So, the problem for qemu-i386 must be in the settings of the flags in clone().

Works:

void test_pthread(void)
{
    pthread_t tid1, tid2;

    pthread_create(&tid1, NULL, thread1_func, "hello1");
    pthread_create(&tid2, NULL, thread2_func, "hello2");
    pthread_join(tid1, NULL);
    pthread_join(tid2, NULL);
    printf("End of pthread test.\n");
}

Works not:

void test_clone(void)
 {
 uint8_t *stack1, *stack2;
 int pid1, pid2, status1, status2;

 stack1 = malloc(STACK_SIZE);
 pid1 = clone(thread1_func, stack1 + STACK_SIZE, CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, "hello1");

 stack2 = malloc(STACK_SIZE);
 pid2 = clone(thread2_func, stack2 + STACK_SIZE, CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, "hello2");

 while (waitpid(pid1, &status1, 0) != pid1);
 while (waitpid(pid2, &status2, 0) != pid2);

 printf("status1=0x%x\n", status1);
 printf("status2=0x%x\n", status2);
 printf("End of clone test.\n");
 }

Nice to hear from you,
Dietmar

[Dietmar Stölting (dietmar-stoelting)]

Hi,
I just compiled the testclone.c with Suse Linux 9.0.
It has a Kernel 2.4.21, so never heard anything in its life about NPTL.
On this 2.4.21 Linux, the testclone program with direct calling of clone() works.
Then I make a try with this testclone on Raspberry Pi and qemu-i386 with -strace.
The same happens as before:
In the clone() number entries, only the numbers of the childstacks are different,
all other in the two threads is the same and the message comes: No child processes
So, the problem in Qemu User mode for a i386 guest depends not on NPTL.
qemu-i386 has a problem, when clone() was called direct, no problem if it is called via pthread_create,
Dietmar

[Dietmar Stölting (dietmar-stoelting)]

Hi,
here are the next steps what I am doing. I get the oldest qemu-0.41 version, that I can get,
from June 2003:-).
Very interesting, the syscall.c today in Qemu 1.2.0 is build exact like that from 2003.
And the testclone.c programm comes together with Qemu 0.41 and compiled also.
So, not so difficult to understand what is going wrong: No NPTL in Qemu from 2003,
the mistakes have been done in this very first version or in a version later. Because I think, that Fabrice can do his own testclone programm in the very first version, it should work.
This I am just testing,
nice to hear from you,
Dietmar

[Dietmar Stölting (dietmar-stoelting)]

Yeeaah,
the first version of qemu-0.4.1 is the ONLY version of Qemu,
that runs the testclone programm without any error.
This is nice, because the structure of calling clone() in syscall.c is today the same as in 0.4.1.
This means, the error can be fixed,
Dietmar

[Peter Maydell (pmaydell)]

Thanks for doing this testing but I'm afraid it really isn't giving us any new information. We already know clone is broken for i386 targets; see my comment #9 in this bug.

[Dietmar Stölting (dietmar-stoelting)]

didi2@linux:~> strace -f qemu testclonenonptl
execve("/usr/local/bin/qemu", ["qemu", "testclonenonptl"], [/* 67 vars */]) = 0
uname({sys="Linux", node="linux", ...}) = 0
brk(0) = 0x80463540
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40019000
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=102185, ...}) = 0
old_mmap(NULL, 102185, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001a000
close(3) = 0
open("/lib/i686/libm.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 5\0\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=183008, ...}) = 0
old_mmap(NULL, 142672, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40033000
old_mmap(0x40055000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x21000) = 0x40055000
close(3) = 0
open("/lib/i686/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320]\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1461208, ...}) = 0
old_mmap(NULL, 1256644, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40056000
old_mmap(0x40182000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12c000) = 0x40182000
old_mmap(0x40187000, 7364, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40187000
close(3) = 0
mprotect(0x80000000, 327680, PROT_READ|PROT_WRITE) = 0
mprotect(0x80000000, 327680, PROT_READ|PROT_EXEC) = 0
munmap(0x4001a000, 102185) = 0
brk(0) = 0x80463540
brk(0x80484540) = 0x80484540
brk(0) = 0x80484540
brk(0x80485000) = 0x80485000
open("/usr/local/qemu-i386", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOENT (No such file or directory)
open("testclonenonptl", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=9503, ...}) = 0
geteuid32() = 500
getegid32() = 100
lseek(3, 0, SEEK_SET) = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\360\203"..., 128) = 128
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000
lseek(3, 52, SEEK_SET) = 52
read(3, "\6\0\0\0004\0\0\0004\200\4\0104\200\4\10\300\0\0\0\300"..., 192) = 192
lseek(3, 244, SEEK_SET) = 244
read(3, "/lib/ld-linux.so.2\0", 19) = 19
open("/lib/ld-linux.so.2", O_RDONLY) = 4
lseek(4, 0, SEEK_SET) = 0
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\f\0"..., 128) = 128
mmap2(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40189000
mprotect(0x40209000, 4096, PROT_NONE) = 0
munmap(0x4001a000, 4096) = 0
mmap2(0x8048000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x8048000
mmap2(0x8049000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0...