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)
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
--
You received this bug notifi
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 diff
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
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_p
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
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_ld
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,
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
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
--
You received this bug notification because y
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
I mean of course, that the tidptr from child and parent are different,
parent_tidptr=0x43076590 child_tidptr=0x42fcb788
Dietmar
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1035572
Title:
Bug
Public bug reported:
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 test
13 matches
Mail list logo
