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 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 unde
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 the
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 prob
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
t
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, 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 ac
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 th
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 w
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
projects:~/upstream/qem
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.
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 archit
12 matches
Mail list logo
