[Pearpc-devel] Compiling on Linux x86-64 for 32bit target

[Jens von der Heydt]

Hi,

I'm currently trying to compile PearPC as a 32bit - binary on SuSE 10.0
but I seem to be having problems with Yasm. I did not install
Nasm since I want to get our Configure-Script to correctly work with
the 64bit environment and Yasm since it will be needed to have a
later jitc_64
and Nasm is dead - by the way.


Yasm is compatible with Nasm code what I had to do was to replace
around 20 lines of assembler that all were PUSHES like this
line from jitc_mmu.asm:


ppc_write_effective_byte_asm:

...
push 8 ; roll back 8 bytes in case of exception
...


Yasm does not like that Syntax, it's something about the Amd64 extension
that they had to change the syntax for.

So one has to write
push byte 8
or
push dword 8


As another thing, of course I had to include "-m32" in CFlags and
CXXFlags.
The Code builds ok but when I start PearPC as soon as JitC starts I
get a
segfault. When I compile the same thing with a (later installed) nasm
(and with changing "push dword 8" back to "push 8") it does compile
and work.

I made sure that Yasm does compile an elf binary and the target
plattform
and arch is x86 (32 bit). Any Ideas what I'm doing wrong here?



Jens

[Sebastian Biallas]

Post by Jens von der Heydt
Hi,
I'm currently trying to compile PearPC as a 32bit - binary on SuSE 10.0
but I seem to be having problems with Yasm. I did not install
Nasm since I want to get our Configure-Script to correctly work with
the 64bit environment and Yasm since it will be needed to have a later
jitc_64
and Nasm is dead - by the way.

Oha. Reference?

Post by Jens von der Heydt
Yasm is compatible with Nasm code what I had to do was to replace
around 20 lines of assembler that all were PUSHES like this
...
push 8 ; roll back 8 bytes in case of exception
...
Yasm does not like that Syntax, it's something about the Amd64 extension
that they had to change the syntax for.
So one has to write
push byte 8
or
push dword 8

Sounds reasonable.

Post by Jens von der Heydt
As another thing, of course I had to include "-m32" in CFlags and
CXXFlags.
The Code builds ok but when I start PearPC as soon as JitC starts I get a
segfault. When I compile the same thing with a (later installed) nasm
(and with changing "push dword 8" back to "push 8") it does compile and
work.
I made sure that Yasm does compile an elf binary and the target plattform
and arch is x86 (32 bit). Any Ideas what I'm doing wrong here?

No.

Post by Jens von der Heydt
Jens

[Jens von der Heydt]

Post by Sebastian Biallas

Post by Jens von der Heydt
Hi,
I'm currently trying to compile PearPC as a 32bit - binary on SuSE 10.0
but I seem to be having problems with Yasm. I did not install
Nasm since I want to get our Configure-Script to correctly work with
the 64bit environment and Yasm since it will be needed to have a
later
jitc_64
and Nasm is dead - by the way.

Oha. Reference?

Well, no real reference except the fact that there are hardly any
developers
still related to the project and no new versions or features
implemented.
That's no problem for PearPC since Nasm has everything we currently
need.
It's just that I recently installed an AMD64-System and would like to
work
on a 64bit Jitc. That won't work with Nasm.

Post by Sebastian Biallas

Post by Jens von der Heydt
So one has to write
push byte 8
or
push dword 8

Sounds reasonable.

Yes, that's what I thought, too. My Problem is that I still get
Segfaults and
a Debug build shows the first problem to be in function
ppc_effective_to_physical_code_ret
in line 418 ( and ecx, 0xfffff000). Why should it segfault at such a
basic line ?!

ppc_effective_to_ph... is called from jitc_tools.asm:779
(ppc_new_pc_asm)
and the line before that call is " push byte 0".

Does it actually make any difference if I used "push byte" or "push
dword" here ?

I really don't think that this is a problem of dword or byte pushed
here. But what could it be then?
I even disassembled a nasm-build .o and compared it with the yasm-
build .o - file. No main difference
at all.


Jens

[Daniel Foesch]

Post by Jens von der Heydt

Post by Sebastian Biallas

Post by Jens von der Heydt
So one has to write
push byte 8
or
push dword 8

Sounds reasonable.

Yes, that's what I thought, too. My Problem is that I still get
Segfaults and
a Debug build shows the first problem to be in function
ppc_effective_to_physical_code_ret
in line 418 ( and ecx, 0xfffff000). Why should it segfault at such a
basic line ?!

The assembly instruction:

and ecx, 0xfffff000

Cannot segfault... unless it's taking it to be a memory address
instead of a constant. But a seg fault can only happen when accessing
memory. It's possible that YASM is generating incorrect code...

Post by Jens von der Heydt
ppc_effective_to_ph... is called from jitc_tools.asm:779
(ppc_new_pc_asm)
and the line before that call is " push byte 0".

You have here "push byte 0" that is INCORRECT, you should be pushing dword!

Post by Jens von der Heydt
Does it actually make any difference if I used "push byte" or "push
dword" here ?

Yes, very much so. In the first case, you place one zero byte on the
stack, then decrement the stack down one byte. If a emulated page
fault is detected, it will be looking for a whole dword value to be
there, not to mention that we will end up with a misalligned stack,
etc etc etc...

Assume everything in the .asm files that is pushing a value is pushing a dword.

Post by Jens von der Heydt
I really don't think that this is a problem of dword or byte pushed
here. But what could it be then?
I even disassembled a nasm-build .o and compared it with the yasm-
build .o - file. No main difference
at all.

This is very likely the problem. Have you not tried changing it and
seeing if it resolves the problem?

--
Daniel Foesch

[Jens von der Heydt]

Post by Jens von der Heydt
and ecx, 0xfffff000
Cannot segfault... unless it's taking it to be a memory address
instead of a constant. But a seg fault can only happen when accessing
memory. It's possible that YASM is generating incorrect code...

Yes, I think that the problem is with YASM here.

Post by Jens von der Heydt

Post by Jens von der Heydt
ppc_effective_to_ph... is called from jitc_tools.asm:779
(ppc_new_pc_asm)
and the line before that call is " push byte 0".

You have here "push byte 0" that is INCORRECT, you should be
pushing dword!

I already tried that since I thought that a dword would be correct.
Actually
I tried every combination that I could think of :)

Post by Jens von der Heydt

Post by Jens von der Heydt
Does it actually make any difference if I used "push byte" or "push
dword" here ?

Yes, very much so. In the first case, you place one zero byte on the
stack, then decrement the stack down one byte. If a emulated page
fault is detected, it will be looking for a whole dword value to be
there, not to mention that we will end up with a misalligned stack,
etc etc etc...
Assume everything in the .asm files that is pushing a value is
pushing a dword.

That could be the problem. Maybe it's not those 25 lines of "push x" but
another push that needed that dword maskerading. I'll check for that.

I also wrote a ticket at the yasm website. Maybe they can help, the
yasm doc
is quite ... well, it's really nothing.

Post by Jens von der Heydt

Post by Jens von der Heydt
I really don't think that this is a problem of dword or byte pushed
here. But what could it be then?
I even disassembled a nasm-build .o and compared it with the yasm-
build .o - file. No main difference
at all.

This is very likely the problem. Have you not tried changing it and
seeing if it resolves the problem?

I did, but I will recheck the whole code.

Thx, for the answer, Daniel.

Jens

[Sebastian Biallas]

Post by Daniel Foesch

Post by Jens von der Heydt
ppc_effective_to_ph... is called from jitc_tools.asm:779
(ppc_new_pc_asm)
and the line before that call is " push byte 0".

You have here "push byte 0" that is INCORRECT, you should be pushing dword!

Äh, you shouldn't be able to actually push *bytes* on an x86. You can
only push things with current operand size (i.e. dwords in almost all
cases nowdays). Even on x86_64 push has an implicit 64 bit prefix.

But there are two different form to push say 0

6a 00 ? push 0
68 00 00 00 00 ? push 0

both will push 0x00000000 (I'm advertising the same service, but HT is
great for this. Press ctrl+a, enter "push 0" and you will see both forms
:) )

[And, on a side note, I guess that "66 68 00 00" is some sort of invalid
operand. At least it breaks the stack alignment]

So, at a closer look it's nonsense that yasm is bitching here. It should
just take the shorter form when in doubt and both forms are
semantically identic.

Sebastian

[Jens von der Heydt]

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

Post by Daniel Foesch

Post by Jens von der Heydt
ppc_effective_to_ph... is called from jitc_tools.asm:779
(ppc_new_pc_asm)
and the line before that call is " push byte 0".

You have here "push byte 0" that is INCORRECT, you should be
pushing dword!

Äh, you shouldn't be able to actually push *bytes* on an x86. You can
only push things with current operand size (i.e. dwords in almost all
cases nowdays). Even on x86_64 push has an implicit 64 bit prefix.

True, that's what I got from the docs too and besides that,
I'm building and ELF or ELF32 binary here. At least with this
switches YASM should be pushing nothing else than 32bit.

But there are two different form to push say 0
6a 00 ? push 0
68 00 00 00 00 ? push 0

I disassembled the ppc binary and saw the second variant to be used
(if objdump does disassemble right here). In both cases - push byte
or push dword -
it does use 68 00 00 00 00.

So, at a closer look it's nonsense that yasm is bitching here. It should
just take the shorter form when in doubt and both forms are
semantically identic.

Yes, it has to be yasm. Why should it segfault on " and ecx,
0xfffff000 " ....

I contacted Yasm devs and they said: "if anything it sounds like a
relocation generation issue.",
so a bug, and that would make sense considering the strange segfault.

Sebastian

Jens