64-bit Linux problem

Anybody that tries to build EE using 64-bit gcc on Linux ends up with an executable that just exits at startup. When run with gdb attached, the only message is "Program exited with code 0377" and breakpoints set in main are NOT reached, which means the program isn't even getting into my code.

WTF is going on, and why is there no information on this anywhere online? I have searched Google til I am sick of looking at it, and all I get are dumbasses talking back and forth at each other with neither one knowing what they're on about.

1. Does a simple hello world program compile and run?

2. Does one of the LibSDL test programs compile and run?

Strange, it must be a somewhat recent change that's done it since I'm sure it worked just fine when I last tried it.

andrewj said:

1. Does a simple hello world program compile and run?

2. Does one of the LibSDL test programs compile and run?

I will try to find out the answer to these.

Strange, it must be a somewhat recent change that's done it since I'm sure it worked just fine when I last tried it.

You have successfully built and run EE as a 64-bit program? O.O It would be the first time I have heard about it working so that would be great.

Last time I tried porting EE to 64-bit Linux I called it a complete architecture and unportable hunk of junk code with tons of compatibility issues and stupid mistakes and assumptions. Seriously.

Also exit code 0377 is octal for 255, which is just -1 where -1 is just exit(-1) or exit(255). Usually an error number that high means it's unknown. If main is never reached, it could be your startup code that could be the problem.

GhostlyDeath said:

Last time I tried porting EE to 64-bit Linux I called it a complete architecture and unportable hunk of junk code with tons of compatibility issues and stupid mistakes and assumptions. Seriously.

Get out of here.

GhostlyDeath said:

Last time I tried porting EE to 64-bit Linux I called it a complete architecture and unportable hunk of junk code with tons of compatibility issues and stupid mistakes and assumptions. Seriously.

MMMMMLLLLLLYYYYYPPPPPPPP

GhostlyDeath said:

Last time I tried porting EE to 64-bit Linux I called it a complete architecture and unportable hunk of junk code with tons of compatibility issues and stupid mistakes and assumptions. Seriously.

Thin ice.

Quasar said:

Get out of here.

You were casting pointer types to int, not using intptr_t, uintptr_t, size_t, etc. Etc. And without breaking the code or rewriting a major portion of the code, nothing could be done really.

I've gotten it to compile before, but it crashed miserably. There's no mention of where the SVN repository is other than http://mancubus.net/svn/eternity which is not checkoutable.

GhostlyDeath said:

http://mancubus.net/svn/eternity which is not checkoutable.

Maybe because it's actually located at http://svn.mancubus.net/svn/hosted/eternity?

GhostlyDeath said:

http://mancubus.net/svn/eternity which is not checkoutable.

http://www.mancubus.net/svn/hosted/eternity/trunk

Type sizes are hardly even a consideration when porting well written code as 99% of it will work just fine as is. Yes you will have inter platform divergence of the size of static buffers, object collections etc but so long as there are no size assumptions in critical sections (e.g., file IO) it doesn't matter (except where they break your own domain standards).

Also, despite what some people would have you believe using iso defined type names is not necessary.

Ghostly and I have had a chat, so no more flames etc. will be necessary. EE's 64-bit portability situation has certainly improved significantly over the past few months. All of the issues to which he refers are ones inherited from the ancestral codebases.

We have eliminated all usage of "long" where it is not specifically mandated by the return types of various functions, and I have converted almost all integer types in the engine to ISO fixed-width, with the exception of some shorts which to my knowledge aren't affected on 64-bit anyway, and those only because I haven't gotten around to fixing them yet. All instances of non-portable pointer cramming have also been eliminated.

EDIT: Ghostly managed to debug the error and found it was the I_Error in Z_Init which wasn't getting a chance to print out for some reason. Turns out I'd thus far forgotten to adjust "HEADER_SIZE" to take 64-bit into account, so sizeof(memblock_t) was too large when bearing 8-byte pointers.

Now it gets to the title screen which is progress; however, it crashes as soon as it tries to render anything, and I can't figure out what's going on. "heightmask" is -1 in R_QDrawColumn, which would indicate that the column texture height is 0. This sounds nonsensical to me. I am trying all kinds of things and so far nothing is working.

Quasar said:

Now it gets to the title screen which is progress; however, it crashes as soon as it tries to render anything, and I can't figure out what's going on. "heightmask" is -1 in R_QDrawColumn, which would indicate that the column texture height is 0. This sounds nonsensical to me. I am trying all kinds of things and so far nothing is working.

Just so you know... it currently only crashes when a middle texture on a two sided line wants to be drawn.

EDIT: or any sprite, sometimes...

Apparently EE 64-bit is now functional! Thanks to everybody that helped out.

It works fine in Doom2, but when I have it try the start map it immediately segfaults. I'll get on IRC tomorrow with GDB reports so we can figure this out.

I'd assume it's due to Small's incompatibility with 64-bit, due to something with the scripts' compiled bytecode that I can't remember the technical explanation for. :\

esselfortium said:

I'd assume it's due to Small's incompatibility with 64-bit, due to something with the scripts' compiled bytecode that I can't remember the technical explanation for. :\

64-bit must be built with the symbol EE_NO_SMALL_SUPPORT enabled. The Small virtual machine is not 64-bit clean and cannot be made so without breaking its compatibility with its own compiler.

It's due to this that we're looking at new scripting solutions such as ECMAScript.

Quasar said:

The Small virtual machine is not 64-bit clean and cannot be made so without breaking its compatibility with its own compiler.

Does it assume pointers and ints are interchangeable, or what?

andrewj said:

Does it assume pointers and ints are interchangeable, or what?

In at least one point it does this, by inlining opcode handler addresses into the bytecode in order to perform direct threaded interpretation (which is as fast as it gets aside from binary translation or virtualization). However it is also coded top to bottom to assume that a "cell," the basic unit of all data in Small, matches the size of the processor word. So on 32-bit, the compiler and VM produce and execute 32-bit bytecode only. On 64-bit, the same situation.

Reversing that design decision would require modification of the entire system, and since the system is already poor for other reasons (the compiler is very unstable), I can't consider it worth even trying.

Quasar said:

Reversing that design decision would require modification of the entire system, and since the system is already poor for other reasons (the compiler is very unstable), I can't consider it worth even trying.

Yeah I can understand.