[Pearpc-devel] cpu_jitc_x86

[Daniel Hazelbaker]

Greetings,

If this e-mail gets through to the list, I am not subscribed so
please CC me with any responses. I downloaded the 0.4 source code
and compile for the cpu_generic version on my Intel iMac. It worked
fine. Slow as molasses, but worked. (with some changes to code and
makefiles to let it compile) When I did the same to cpu_jitc_x86 it
compiles but as soon as it tries to begin emulating it crashes. When
I run it under the debugger the stack has been smashed. Does anybody
have any thoughts as to why it is crashing (any known bugs)? And
also, does anybody have some recommendations for debugging? Any
functions I should set breakpoints on that might help track down
exactly where it is crashing without single stepping through the
whole thing?

Daniel Hazelbaker

[Sebastian Biallas]

Post by Daniel Hazelbaker
Greetings,
If this e-mail gets through to the list, I am not subscribed so
please CC me with any responses. I downloaded the 0.4 source code and
compile for the cpu_generic version on my Intel iMac. It worked fine.
Slow as molasses, but worked. (with some changes to code and makefiles
to let it compile) When I did the same to cpu_jitc_x86 it compiles but
as soon as it tries to begin emulating it crashes.

That's an interesting test. I guess no one has tried it on Intel Macs yet :)

But I have no idea why it crashes. Does it accomplish the CPU
identification? (Do you see the "MMX SSE blabla" line before it crashes?)

Post by Daniel Hazelbaker
When I run it under
the debugger the stack has been smashed.

Well, that's sort of normal. Pearpc is unwinding the stack in a non
debugger friendly way.

Post by Daniel Hazelbaker
Does anybody have any thoughts
as to why it is crashing (any known bugs)? And also, does anybody have
some recommendations for debugging? Any functions I should set
breakpoints on that might help track down exactly where it is crashing
without single stepping through the whole thing?

Set a breakpoint to ppc_cpu_run() in file src/cpu_jitc_x86/ppc_cpu.cc:126

If it reaches there the problem is tricky...

Post by Daniel Hazelbaker
Daniel Hazelbaker

Sebastian

[Daniel Hazelbaker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Daniel Hazelbaker
Greetings,
If this e-mail gets through to the list, I am not subscribed so
please CC me with any responses. I downloaded the 0.4 source code and
compile for the cpu_generic version on my Intel iMac. It worked fine.
Slow as molasses, but worked. (with some changes to code and
makefiles
to let it compile) When I did the same to cpu_jitc_x86 it
compiles but
as soon as it tries to begin emulating it crashes.

That's an interesting test. I guess no one has tried it on Intel Macs yet :)
But I have no idea why it crashes. Does it accomplish the CPU
identification? (Do you see the "MMX SSE blabla" line before it crashes?)
[snip]
Set a breakpoint to ppc_cpu_run() in file src/cpu_jitc_x86/
ppc_cpu.cc:126
If it reaches there the problem is tricky...

It's going to be tricky... :) I'll try to get a diff made that
hopefully somebody will see something wrong in, but I fear I have
localized the problem to a relocation table error.

GenuineIntel
CMOV MMX SSE SSE2 SSE3
[CPU/MMU] new pagetable: sdr1 = 0x00300003
[CPU/MMU] new pagetable: sdr1 accepted
[CPU/MMU] number of pages: 2^15 pagetable_start: 0x00300000 size: 2^18
start: 512
start: 32768
getStartBlock: 0 Apple_Driver43
[Snip a bunch of device access stuff]
getStartBlock: 9 Apple_HFS
[CPU/CPU] execution started at 05601028
Illegal instruction

That "Illegal instruction" is me trying to jmp to a global definition
inside of jitc_mmu.asm from jitc_tools.asm. Everything works fine
until it hits ppc_new_pc_asm and the call to the other file. So I
think nasm (or maybe ld) is not properly setting the link order. My
asm is a bit rusty, but what I have been doing to track down how far
it gets is moving an infinite loop (label: jmp label) around to find
the crash. At this point, I have two ideas for how to proceed.
First, move jitc_mmu.asm into jitc_tools.asm and see if it works fine
(or at least better) that way. Second, get a CVS snapshot of nasm
and see if anything in CVS is better than what I got from Apple a
month ago (doubtful).

But if anybody else has any better ideas, All ears. :)

I'm hoping I can find a way to make this work. With the speed I have
seen on this intel iMac (easily 4x as fast as my G4 laptop), pearpc
gives me a possible viable solution for sandbox machines... (Who
would'a thought of using an intel mac to emulate a PowerPC mac? Now
if I can just get MOL in there somehow....) :)

Daniel

[Daniel Hazelbaker]

Okay, I have attached a gzip of the patch file to let the .asm files
work correctly. nasm seems to accept -D preprocessor macros so maybe
some kind of "-DFUNCPREFIX=_" can be used when building on Darwin.

I am at this point pretty stumped for how to get pearpc to go any
farther. Moving all the .asm source into the same file seemed to fix
the initial problem. It now correctly calls
_ppc_effective_to_physical_code to, I believe, translate a ppc
instruction. However, it never finds a translation for it so "falls
through" into ppc_isi_exception_asm which eventually crashes the
program by starting the whole process again. I don't know what
"normal" (the fall through part) or not so I don't know if I should
be debugging the fact that it is crashing, or the fact that it is not
finding anything in the lookup table.

Right up until it tries to translate that first instruction, it sure
is fast! ;-)

Daniel

[Sebastian Biallas]

Post by Daniel Hazelbaker
Okay, I have attached a gzip of the patch file to let the .asm files
work correctly. nasm seems to accept -D preprocessor macros so maybe
some kind of "-DFUNCPREFIX=_" can be used when building on Darwin.

nasm already supports this.. take a look at configure.in and how this is
handled on windows.

I.e. something like
NASM_OPTS="--prefix _ -f macho"
in the correct 'case "$target_os" in' should do. I don't know in which
case Mac OS X falls, darwin perhaps?

I wonder how you actually got this linked in the first place without
this option?!


Sebastian

[Daniel Hazelbaker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Daniel Hazelbaker
Okay, I have attached a gzip of the patch file to let the .asm files
work correctly. nasm seems to accept -D preprocessor macros so maybe
some kind of "-DFUNCPREFIX=_" can be used when building on Darwin.

nasm already supports this.. take a look at configure.in and how this is
handled on windows.
I.e. something like
NASM_OPTS="--prefix _ -f macho"
in the correct 'case "$target_os" in' should do. I don't know in which
case Mac OS X falls, darwin perhaps?
I wonder how you actually got this linked in the first place without
this option?!

God only knows. :) I'll try a run like that. I manually modified the
configure script to use -f macho instead of elf by default (quick
fix, I tried modifying a configure script once to include Darwin and
I still have nightmares from it). And I manually modified the .asm
files to use an _ prefix. Unfortunately the man file for nasm on
Darwin/Mac does not appear to be complete. It does not have --
prefix, nor does it say what -O is.

... Okay, found the spot to add the NASM flags to in the configure
script and re-ran it, Had to comment 2 lines to make it build but we
are good to go as far as building now. It still seems to have a
problem with the relocation table and calling functions in the
other .asm file. I wonder, if the relocation table is jacked and
when it tries to call a function in another file... Maybe all the
variable relocations are jacked too and that is why the instruction
lookup (appeared) did not work. I'll have to see if I can devise a
simple .asm function that returns the address of a global variable
and then compare them.

Thanks for your help so far. I'll see if I can verify the relocation
table problem. If Apple's nasm mach-o support is harfed then maybe I
can get some help on their lists for that part of it.

Sebastian

Daniel

[Sebastian Biallas]

Post by Daniel Hazelbaker
... Okay, found the spot to add the NASM flags to in the configure
script and re-ran it, Had to comment 2 lines to make it build but we are
good to go as far as building now.

Can you send me the binary so I can have a look with a hex editor?

Post by Daniel Hazelbaker
It still seems to have a problem
with the relocation table and calling functions in the other .asm file.
I wonder, if the relocation table is jacked and when it tries to call a
function in another file... Maybe all the variable relocations are
jacked too and that is why the instruction lookup (appeared) did not
work. I'll have to see if I can devise a simple .asm function that
returns the address of a global variable and then compare them.

I currently seeking for an alternative for nasm. nasm has some strange
bugs, seems no longer supported and has no x86_64 support. yasm doesn't
look better either. Maybe I have to convert the asm files to gnu as, I
guess this should solve these issues.

Sebastian

[Jens von der Heydt]

Post by Sebastian Biallas
I currently seeking for an alternative for nasm. nasm has some strange
bugs, seems no longer supported and has no x86_64 support. yasm doesn't
look better either. Maybe I have to convert the asm files to gnu as, I
guess this should solve these issues.
Sebastian

Regarding nasm, you might remember me talking about yasm on the list.
It had allocation problems but they fixed it, it does work work with
pearpc now. Maybe you want to have a look at it, Sebastian.

The latest snapshot does work with pearpc.

Jens

[Daniel Foesch]

Post by Jens von der Heydt

Post by Sebastian Biallas
I currently seeking for an alternative for nasm. nasm has some strange
bugs, seems no longer supported and has no x86_64 support. yasm doesn't
look better either. Maybe I have to convert the asm files to gnu as, I
guess this should solve these issues.
Sebastian

Regarding nasm, you might remember me talking about yasm on the list.
It had allocation problems but they fixed it, it does work work with
pearpc now. Maybe you want to have a look at it, Sebastian.
The latest snapshot does work with pearpc.

I continue to support gas, myself. Plus, the benefit is that if we move on
to supporting more archs than just x86, then we don't have to go looking for
a new assembler, we can continue to use gas.

And if someone is compiling with gcc, then they're already assembling with
gas.

The only thing is that it would make supporting non-AT&T syntax assemblers
pretty annoying (like, Visual Studio)


--
Daniel Foesch

[Jens von der Heydt]

Post by Jens von der Heydt
Regarding nasm, you might remember me talking about yasm on the list.
It had allocation problems but they fixed it, it does work work with
pearpc now. Maybe you want to have a look at it, Sebastian.
The latest snapshot does work with pearpc.
I continue to support gas, myself. Plus, the benefit is that if we
move on to supporting more archs than just x86, then we don't have
to go looking for a new assembler, we can continue to use gas.
And if someone is compiling with gcc, then they're already
assembling with gas.
The only thing is that it would make supporting non-AT&T syntax
assemblers pretty annoying (like, Visual Studio)
--
Daniel Foesch

true, plus we had to rewrite most of the existing assembler to use
gas...
Hmmmmm

Jens

[Sebastian Biallas]

Post by Daniel Foesch
The only thing is that it would make supporting non-AT&T syntax
assemblers pretty annoying (like, Visual Studio)

gas supports intel-style (".intel").

The only things I currently haven't found in gas is the "--prefix _".
Under Windows (and, according to this thread, Darwin) all symbols have
to be prefixed with '_'. I don't know how to tell this to gas or ld.

Sebastian

[Daniel Foesch]

Post by Sebastian Biallas

Post by Daniel Foesch
The only thing is that it would make supporting non-AT&T syntax
assemblers pretty annoying (like, Visual Studio)

gas supports intel-style (".intel").

Yeah, well, I prefer to use AT&T syntax myself. Once I got used to it, I
liked having the size indicated in the mnemonic. Makes it much easier to
distinguish between "pushb 1" and "pushw 1" especially.


The only things I currently haven't found in gas is the "--prefix _".

Post by Sebastian Biallas
Under Windows (and, according to this thread, Darwin) all symbols have
to be prefixed with '_'. I don't know how to tell this to gas or ld.
I can't find anything... best I can think is to make the files .S so that

they go through the C preprocessor, then you could use
-D__UNDERSCORE_PREFIX__ then give it:

#ifdef __UNDERSCORE_PREFIX__
_label:
#else
label:
#endif

But that seems like much too of a horrible work-around to want to use it in
our code.

--
Daniel Foesch

[Sebastian Biallas]

Post by Jens von der Heydt
Regarding nasm, you might remember me talking about yasm on the list.
It had allocation problems but they fixed it, it does work work with
pearpc now. Maybe you want to have a look at it, Sebastian.

Did they also fix the stupid "push dword 1" vs. "push byte 1" issue? Did
they implement the --prefix option?

Post by Jens von der Heydt
Jens

Sebastian

[Jens von der Heydt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Jens von der Heydt
Regarding nasm, you might remember me talking about yasm on the list.
It had allocation problems but they fixed it, it does work work with
pearpc now. Maybe you want to have a look at it, Sebastian.

Did they also fix the stupid "push dword 1" vs. "push byte 1"
issue? Did
they implement the --prefix option?

Post by Jens von der Heydt
Jens

Sebastian

I think this byte / dword masking only affected my attempts to compile
for amd64. I used yasm with a clean cvs copy and it build, therefore
I suspect it to be compatible. I did not have to supply a --prefix,
but I'll check
if it does support it. It's been some time since I played around with
pearpc
and yasm

Jens

[Sebastian Biallas]

Post by Jens von der Heydt
I think this byte / dword masking only affected my attempts to compile
for amd64.

Then they fixed it. What code does yasm generate for "push 1"?

Post by Jens von der Heydt
Jens

Sebastian

[Sebastian Biallas]

Post by Daniel Hazelbaker
... Okay, found the spot to add the NASM flags to in the configure
script and re-ran it, Had to comment 2 lines to make it build but we are
good to go as far as building now. It still seems to have a problem
with the relocation table and calling functions in the other .asm file.

Looking at the disassembly: Is this compiled with -fpic or -dPIC
(postition independent code) or somethings like that? I recently noticed
that pearpc doesn't like this...

Sebastian