The Linux 64 bit port is broken

[GoogleCodeExporter]

There were actually two causes of this. The compilation was broken in trunk
during the move to C++, because C++ is stricter then C in what it allows.
This was patched by adding -fpermissive as a flag.

However, as of revision 317, even if you add that flag, it now stalls
infinately on startup, after the following output:

GIF reset
Framelimiter rate updated (UpdateVSyncRate): 59.94 fps NTSC
IOP Recompiler data reset
_openfile /usr/local/src/pcsx2/bin/isos/kh1.iso 0
detected blocksize = 2048
isoOpen: /usr/local/src/pcsx2/bin/isos/kh1.iso ok
offset = 0
blockofs = 24
blocksize = 2048
blocks = 1478048
type = 2
ZeroGS: creating
ZeroGS: Got Doublebuffered Visual!
ZeroGS: glX-Version 1.3
ZeroGS: Depth 24
ZeroGS: you have Direct Rendering!
ZeroGS: Disabling MRT depth writing
ZeroGS: Creating effects
ZeroGS: Creating extra effects
ZeroGS: using accurate shaders
ZeroGS: initialization successful
gsOpen done
MTGS thread unlocked
Starting GS thread
Using Frame Skipping: Normal
Framelimiter rate updated (UpdateVSyncRate): 59.94 fps
* PCSX2 *: ExecuteBios
loadcore RegisterLibraryEntries (3af0): excepman
loadcore RegisterLibraryEntries (526c):  intrman
loadcore RegisterLibraryEntries (5f1c):   ssbusc
loadcore RegisterLibraryEntries (75c0):  dmacman
loadcore RegisterLibraryEntries (837c):  timrman
loadcore RegisterLibraryEntries (9dcc):  sysclib
loadcore RegisterLibraryEntries (9dcc):    stdio
loadcore RegisterLibraryEntries (a9a0):  heaplib
loadcore RegisterLibraryEntries (10cf0):   thbase
loadcore RegisterLibraryEntries (10cf0):  thevent
loadcore RegisterLibraryEntries (10cf0):  thsemap
loadcore RegisterLibraryEntries (10cf0):  thmsgbx
loadcore RegisterLibraryEntries (10cf0):  thfpool
loadcore RegisterLibraryEntries (10cf0):  thvpool
intrman RegisterIntrHandler (10d34): intr INT_RTC5, handler fcb0
loadcore RegisterLibraryEntries (1262c):   vblank
intrman RegisterIntrHandler (12650): intr INT_VBLANK, handler 122a4
intrman RegisterIntrHandler (12650): intr INT_EVBLANK, handler 1235c
loadcore RegisterLibraryEntries (13ae8):    ioman
loadcore RegisterLibraryEntries (15558):  modload
loadcore RegisterLibraryEntries (160ec):   romdrv
loadcore RegisterLibraryEntries (1692c):    stdio
loadcore RegisterLibraryEntries (1789c):   sifman

PlayStation 2 ======== Hard reset boot
 ROMGEN=2003-0325, IOP info (CPUID=1f, CACH_CONFIG=1edd8, 2MB, IOP mode)
 <20030325-181554,ROMconf,PS20170AC20030325.bin:11648>
intrman RegisterIntrHandler (178c0): intr INT_dmaSIF0, handler 16d94

--

Revision 317 was a big update, and the issue will take a while to track
down. It is low priority, simply because we had already expected that x64
would break when some major changes are made to the recompiler, and we had
been contemplating removing support for it.

Main trouble is that I'm the only one working on the 64 bit side of things,
and I'm not likely to be able to keep major changes in sync to the recompiler. 

I'll keep looking at it, and if anyone manages to fix the 64 bit port,
please attach a patch, and I'll check it over and commit it.

And if anyone is knowledgable about x86-64 and recompiling, and wants to
work on this, please see cottonvibes or rama2 about becoming a team member.

Original issue reported on code.google.com by arcum42@gmail.com on 16 Nov 2008 at 5:57

[GoogleCodeExporter]

Note: even if the issue from revision 317 gets resolved, I'll leave this open 
for the
next major x64 breakage.

Original comment by arcum42@gmail.com on 16 Nov 2008 at 5:58

[GoogleCodeExporter]

I only made two changes to the recompiler that should have affected anything
functionally.  Both of those changes are in the iR3000a recompiler, and not the
iR5900 recompiler.  The R3000a (IOP) has no specialized 64 bit version though, 
so I
dunno what to think.  The main thing I did was add a single basic ADD32ItoM
instruction after bios calls.  It should have been completely harmless to the 
64 bit
build.  I also made some changes to how the IOP cycles through its branches 
though,
and if there's some IOP code mirrored in the 64 bit folders that I'm not aware 
of, it
might be the culprit.

Namely, the EEsCycles global var is handled differently now.  If there's any 
code in
the 64 bit build that acts on that code, then it should be double checked for 
proper
mirroring of the working 32 bit code.

(this mirrored code between the recompilers of 32 and 64 bits could indeed get 
old
fast -- I was looking at iR5900-64 for that matter and it appears to have a 
handful
of small code cleanups and other improvements that the 32 bit version lacks, so 
it
goes both ways .. it sure would be nice to only have to worry about one or the 
other.)

Original comment by Jake.Stine on 17 Nov 2008 at 4:49

[GoogleCodeExporter]

The handful of minor cleanups may have been me. I committed various changes 
trying to
get any changes I'd noticed had been made to iR5900-32.c in playground, and 
then from
0.92 - 0.9.4, and I think I cleaned up a few minor things in there while I was 
doing
that.

Since that, well, things I do in the group generally are make sure the Linux 
build
keeps compiling, and mirror iR5900-32.c, any time I see changes made. In the 
sections
that are the same, anyways.

I'd actually meant to apply a few cleanups to iR5900-32.c, too; I just never 
got to
it. Gcc nags me about it enough to justify it.

And, you know, I bet ADD32ItoM was what did it. Half the changes to ix86.c made 
in r4
broke Linux 64, and one of the ones that didn't get reverted, because it seemed 
to be
working properly was ADD32ItoM. I'll have to test that, because the symptoms had
aready been reminding me of that breakage...

Original comment by arcum42@gmail.com on 17 Nov 2008 at 12:50

[GoogleCodeExporter]

Or, wait, maybe that one was reverted. Oh well, long day...

Original comment by arcum42@gmail.com on 17 Nov 2008 at 12:53

[GoogleCodeExporter]

I suspect the problem is in x86/aR3000A.S. Despite being directly in the x86 
folder,
most of the file is in an ifdef applying only to x64, and makes use of 
EEsCycle, so
if that's majorly changed, that could easily have affected it.

Original comment by arcum42@gmail.com on 2 Dec 2008 at 3:33

[GoogleCodeExporter]

Yeah, right around line 42, you can see in the comments that it is mirroring a 
spot
in iR3000A.cpp that was changed *in assembly*. Unfortunately, assembly isn't 
exactly
my strong suit...

Original comment by arcum42@gmail.com on 2 Dec 2008 at 3:44

[GoogleCodeExporter]

Try the attached patch.  As you'll see the modification was simple, and I hope 
it's
all that is needed.  I changed the code such that the iR3000A's branchtest code
manages the EEsCycle counts, which was in part an optimization (requires one 
less
while loop) and also better emulation since the branchtest codes knows better 
when
exactly it should exit.

In the old method, the IOP would run indefinitely until it performed an actual
psxBranchTest call which could have been dozens or hundreds of cycles later 
than what
the EE requested.

Original comment by Jake.Stine on 2 Dec 2008 at 5:00

Attachments:

• aR3000A.s.patch

[GoogleCodeExporter]

Hmmm... That's clearly on the right track, as it gets a lot further. Oddly, it 
now
gets to the point of loading pnatches, passes control to ZeroGS, then quits. 
Not even
with an error. 

I may very well commit that change anyways, just because it's a step in the 
right
direction... 

Original comment by arcum42@gmail.com on 2 Dec 2008 at 5:19

[GoogleCodeExporter]

In fact, it works when applied to 317. The second break is from a later 
revision...

Time for some testing...

Original comment by arcum42@gmail.com on 2 Dec 2008 at 5:38

[GoogleCodeExporter]

Now I don't know what the break was from, since I can't reproduce it with this 
patch.
Oh well; I went ahead and committed.

Original comment by arcum42@gmail.com on 2 Dec 2008 at 6:59

[GoogleCodeExporter]

The Linux port is currently not broken. I will leave this open, though, as I 
expect
it to break again eventually.

Original comment by arcum42@gmail.com on 3 Dec 2008 at 11:51

• Changed state: Started

[GoogleCodeExporter]

Original comment by arcum42@gmail.com on 4 Dec 2008 at 6:46

• Changed title: The Linux 64 bit port is (not currently) broken

[GoogleCodeExporter]

I suppose I should note here that currently both Linux ports are broken. Oh 
well,
I'll figure out how to fix the linkage one of these days. Practically eveything 
is
ix86 gives undefined references in x86...

Original comment by arcum42@gmail.com on 17 Dec 2008 at 11:56

[GoogleCodeExporter]

@@#!$!$%

It's all the bloody functions with _inline in front of them in ix86.c doing it. 
I
just commented out all occurrances of _inline in that file, and half the linker
errors vanished. Now, to figure out a better way to get rid of them. 

Presumably, its inconsistancies between ix86.h and all the million files it is a
header for doing it.

Original comment by arcum42@gmail.com on 17 Dec 2008 at 12:30

[GoogleCodeExporter]

Usually adding "extern" to the prototypes fixes _inline type linker errors.

Original comment by Jake.Stine on 17 Dec 2008 at 2:59

[GoogleCodeExporter]

They already are extern. The function declarations in the header don't mention 
them
being _inline, though, and there are enough that are __forceinline, or not 
inlined at
all, that I can't just do a search and replace...

Original comment by arcum42@gmail.com on 17 Dec 2008 at 8:06

[GoogleCodeExporter]

So I've got an idea of how to proceed, it's just going to be a major hassle.
Fortunately, my weekend is coming up...

Original comment by arcum42@gmail.com on 17 Dec 2008 at 8:21

[GoogleCodeExporter]

Adding _inline to prototypes shouldn't matter.
Does changing them to __forceinline fix them?  Other forceinlines work, right?

Original comment by Jake.Stine on 17 Dec 2008 at 8:34

[GoogleCodeExporter]

__forceinlining them does work, so for expediency, for the moment, all _inlines 
will
become __forceinlines. We can change them later if neccessary, if need be.

The other main breakers are calls to and from assembly files. I'm wrapping the 
calls
to them in extern "C" for the moment. From, I'll have to look at a bit closer...

Original comment by arcum42@gmail.com on 18 Dec 2008 at 11:32

[GoogleCodeExporter]

All right, that's the 32 bit port taken care of. I still need to look at the 64 
bit port.

Original comment by arcum42@gmail.com on 18 Dec 2008 at 12:09

[GoogleCodeExporter]

Original comment by arcum42@gmail.com on 20 Dec 2008 at 8:45

• Changed title: The Linux 64 bit port is broken

[GoogleCodeExporter]

Given recent announcements, I think I can close this. :(

Original comment by arcum42@gmail.com on 25 Dec 2008 at 12:33

• Changed state: WontFix