Re: [Qemu-devel] linux-user target

[J. Mayer]

On Wed, 2007-04-18 at 13:31 -0400, Stuart Anderson wrote:
> On Tue, 17 Apr 2007, Stuart Anderson wrote:
> 
> > I've continued to work on this all week, and I still haven't managed to
> > solve it. I've chased down a lot of paths, but none of them have lead to
> > a solution. Here is a summary of the situation now.
> >
> > * programs other than bash will run
> > * bash --version will run
> > * bash --noediting will run
> > * occasionally, bash has run if I'm stracing it, but I can't always
> >   reproduce it.
> > * when it runs, I occasionally see some odd behavior, but not always.
> >   The termios patch I just sent cleared up a lot of the oddness.
> > * when it runs, it hangs on exit. Killing it logs me all the way out
> >   of the system (ssh conection).
> > * when it crashes, gdb looses the user level thread, so I can't do any
> >   debugging
> > * I don't see any of the TLS related system calls being called. I also
> >   don't see any concrete proof one way or another that it is used in
> >   the executable (ie No R_PPC_*TLS relocations). I've been digging in
> >   the kernel & glibc source, and I don't see a lot of special code to
> >   support TLS on ppc. It mostly seems to be just taking care to not
> >   step on R2. Glibc seems to be the only place where it knows something
> >   specific about TLS, which leads me to think that TLS is mostly
> >   contain within the userspace on PPC.

You're right: I think all TLS specific code is located in the glibc.

> > * I've tried turning on most of the DEBUG_ defines under linux-user,
> >   but none of them has yielded anything useful, or noteworthy.
> 
> This morning, I went back and tried a 32-bit x86 host (instead of the
> x86_64 host), and discovered that everything works just fine. This makes
> me think it's a 64 bit issue, so I took a closer look at the build warnings
> that exist on x86_64 but not on x86. This pointed to PPC_OP(goto_tb0) &
> PPC_OP(goto_tb1) in target-ppc/op.c. It appears that x86_64 is using the
> generic portable code, but one of the fields that it is taking as a
> pointer (tb_next) is only an int. Changing it to a ulong didn't fix
> things though, but it did eliminate the warning.
> 
> After more digging in the qemu.log, I noticed this difference that is
> related to those two functions (op_goto_tb0 & op_goto_tb1).
[...]
> Is this correct? Would it cause any kind of a problem?

I don't think this is the problem.
- those functions are also used for system emulation. So the bug would
not be restricted to user mode emulation if this was the source of the
problem
- my development machine is an amd64 one and the test I did in a
previous mail were done on this machine, in 64 bits mode. So I'm quite
sure linux-user is able to run on a 64 bits host. There may still be 64
bits related bugs in Qemu but it seems the major ones have already been
fixed. It may be related to some of the library versions installed in
your 64 bits environment that would not be the same as the one used in
the 32 bits environment.
- I'm not a specialist of the x86 architecture but the generated code
seems correct to me and I don't think the repz instruction is so
important in that particular case (but I may be wrong). One important
precision that may make a big difference: I always use gcc 3.4 to
compile because I know several  gcc 4.x bugs (crash during ISO C
compliant code and/or incorrect generated asm instructions), then I do
not consider gcc 4.x as usable for a production environment today. Maybe
this is the reason why Qemu runs OK on my machine but not on yours.
For your information, my testing system is an up-to-dat Gentoo Linux
distribution. My 32 bits test environment is another Gentoo distribution
in a chrooted environment, running on the same machine.

-- 
J. Mayer <address@hidden>
Never organized