On Wed, 2007-04-18 at 16:42 -0400, Stuart Anderson wrote:
On Thu, 19 Apr 2007, Igor Kovalenko wrote:
as discussed before, to do this in dyngen you need to know the context
better or you'll skip more than intended; that amounts to moving a
large bit of decoder there as far as I understand
On Thu, 19 Apr 2007, J. Mayer wrote:
And I checked the code generated on my machine.
I got the repz at the end of the op_goto_tb0 and op_goto_tb1 and it
seems to work well here with the bash version I got.
IIrc from yesterday, they ended up in front of lea instuctions, which
I think always
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
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
On Wed, 18 Apr 2007, J. Mayer wrote:
You're right: I think all TLS specific code is located in the glibc.
In my last tracing through qemu.log, I did check for r2 references, and
there was one store near the beginning that looked like what glibc would
do (r2 = ptr+0x700), and the rest of the
On 4/18/07, Stuart Anderson [EMAIL PROTECTED] wrote:
On Wed, 18 Apr 2007, J. Mayer wrote:
You're right: I think all TLS specific code is located in the glibc.
In my last tracing through qemu.log, I did check for r2 references, and
there was one store near the beginning that looked like what
On Wed, 18 Apr 2007, Igor Kovalenko wrote:
This should be solved for x86_64 host with -mtune=nocona patch
posted a while ago.
I'll go dig that up.
The problem is with dyngen being confused by repz retq sequence.
That's what caught my attention earlier today. It was only showing up in
two
On 4/19/07, Stuart Anderson [EMAIL PROTECTED] wrote:
On Wed, 18 Apr 2007, Igor Kovalenko wrote:
This should be solved for x86_64 host with -mtune=nocona patch
posted a while ago.
I'll go dig that up.
Here, http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00198.html
The problem is
On Thu, 19 Apr 2007, Igor Kovalenko wrote:
as discussed before, to do this in dyngen you need to know the context
better or you'll skip more than intended; that amounts to moving a
large bit of decoder there as far as I understand that
Yes, it was a quick hack along w/ visual inspection of
On Tue, 10 Apr 2007, Jocelyn Mayer wrote:
PPC:
I am unable to get any executable to run.
projects:~/upstream/qemu# ./ppc-linux-user/qemu-ppc -L /mirror0/chroots/ppc/
/mirror0/chroots/ppc/bin/bash
init_ppc_proc: PVR 0008 mask = 0008
Segmentation fault
On Tue, 2007-04-10 at 09:34 -0400, Stuart Anderson wrote:
I'm trying to test my fixes to the linux-user emulation on some additonal
architectures now, but I'm running into problems. I can debug these some,
but any suggestions or guidence, especially from people more familiar
with the
On Tue, 10 Apr 2007, Jocelyn Mayer wrote:
Just checked, on an amd64 host with a random powerpc bash version I got
on my hard disk drive:
I also tried to really launch the shell and use it and it worked.
Interesting...
But I think recent builds using glibc with TLS/NPTL would not run.
Ahh.
12 matches
Mail list logo
