Any gotchas with developing on a 64 bit OS?

[snow]

My laptop died the other day and I replaced it with a new dual core AMD Turion laptop which is 64 bit. I rebuilt my psp development environment and managed to compile my snes9x port project fine.

When debugging I'm getting errors in memory allocation where I had none before. I'll be digging into it more momentarily but I wanted to ask in case there was anything obvious I don't know about.

[Chrighton]

I don't know if our problems are related. While I'm not under a 64bit OS, I've also been having strange memory issues on my project; works fine under an older pspsdk setup, but recently I've had to reinstall windows, rebuilt everything just fine, but the same psp source which had no memory issues before, now does. I haven't messed with the source at all. The crashes are occuring in _malloc_r/_free_r (or something like this, going from memory), and don't necessarily happen straight away. Heap corruption would be an easy guess, but on another machine where I have an older pspsdk, the same source builds ok, and no crashes in _malloc_r/_free_r at all. ???

[snow]

That's exactly what I was seeing. When the program starts up it's allocating blocks of memory and that fails so it makes calls to free the memory and croaks there as well. I'm hoping I'm just missing a define or something similar. I'll debug and see where things are going haywaire.

[J.F.]

The most common 64 bit programming error is forgetting that pointers aren't 32 bits anymore (on x86_64 at least... some 64 bit CPUs still use 32 bit pointers). So if you store a pointer to an int variable, you lose the top 32 bits of the pointer address. stdint.h makes defines for various types, so be sure to use something suitable to the CPU. uint64_t would work fine for holding a pointer in 64 bit mode.

[cheriff]

The most common 64 bit programming error is forgetting that pointers aren't 32 bits anymore (on x86_64 at least... some 64 bit CPUs still use 32 bit pointers). So if you store a pointer to an int variable, you lose the top 32 bits of the pointer address. stdint.h makes defines for various types, so be sure to use something suitable to the CPU. uint64_t would work fine for holding a pointer in 64 bit mode.

But if i understand the OP correctly, he's still cross compiling for a 32bit arch, just doing so from a 64bit host. That shouldn't affect sizeof(void*) in the generated .ELFs

[snow]

J.F.,

Good point. Having a 64 bit architecture is having a 64 bit address space. Pointers being an address in memory and all it just follows that it would need to be wider than the 32 bit I've been on for a decade or more.

cheriff,

Yeah, that's what the case is. I'm compiling a 32 bit PSP app on 64 bit OS. Given Chrighton's feedback I'm going to try to pull down an earlier SVN revision and compile with that (assuming anything has changed in the last 2-3 weeks when I got the SDK last). Pending those results I'll either reinstall 32 bit Ubuntu or be on my merry way. I'll report back later.

[jimparis]

If you post a simple example of code that shows the bug, perhaps someone else can help point out the problem.

[snow]

I haven't had a lot of time to tool around with it but I'll see if I can't jam something out. I'm still trying to figure out why some malloc calls succeed while others fail. Also this is a port of snes9x so I'm still learning the ins and outs. Once I can isolate and repeat this issue I'll post back.

And hello from another Boston area resident. I work in the financial district but I live about a half hour south of town. Probably a good idea to work from home tomorrow ;)

[gambiting]

Just a guess - if he builded whole toolchain under 64bit OS,then he has PSP-GCC and PSP-G++ build in 64bit versions.I know that they will compile code for PSP cpu,but it may have some characteristics of 64bit code - for example,64bit gcc will replace LONG INT with LONG LONG INT as it's 64bit variable,and thus it's executed faster on 64bit cpus.But what the compiler does NOT know is that psp cpu is 32bit(64bit compiller can't create 32bit executables).And 64bit executables CAN be executed(well,in most cases) on 32bit machine,but it will take 2x time to execute(as all variables are 64bit,and require two cycles of processing time).That's how I understand it,but I may be wrong.

[zilt]

I'm running 64bit Linux:

$ uname -a
Linux trinity 2.6.23.11 #1 SMP PREEMPT Mon Dec 17 21:44:20 EST 2007 x86_64 Dual Core AMD Opteron(tm) Processor 270 AuthenticAMD GNU/Linux

I also probably update and rebuild the full toolchain once a month or so - and have no problems compiling any PSP programs. My own psp program is over 10k lines of code and have no problems compiling and running it under 3 different CFW versions. Anyways, just another data point...

[cheriff]

Just a guess - if he builded whole toolchain under 64bit OS,then he has PSP-GCC and PSP-G++ build in 64bit versions.I know that they will compile code for PSP cpu,but it may have some characteristics of 64bit code - for example,64bit gcc will replace LONG INT with LONG LONG INT as it's 64bit variable,and thus it's executed faster on 64bit cpus.But what the compiler does NOT know is that psp cpu is 32bit(64bit compiller can't create 32bit executables).And 64bit executables CAN be executed(well,in most cases) on 32bit machine,but it will take 2x time to execute(as all variables are 64bit,and require two cycles of processing time).That's how I understand it,but I may be wrong.

Sorry gambiting, this is not correct. The compiler very much does know that the psp is 32 bits, it's pretty fundamental.
Whilst is might be possible that some 64bit characteristics leak into output code, that would be indicative of a bug in the cross compiler. There's no reason why a mips-32 cross compiler built to run natively on a 64bit host will not do the correct thing. In fact, I'd probably be surprised if the the same version of gcc didn't produce bit-for-bit identical binaries when cross compiling from any flavour of host. (given identical commandlines)

And I'm not sure about 64bit executables on 32bit machines? Arches that 'evolved' to 64bits such as mips and x86 usually retain backwards compatibility with 32bit code. One cant go the other way. (that I know of - perhaps with some crazy emulation software, but that'd be way more than twice as slow!)

[J.F.]

Yeah, I'm doing my PSP stuff on 64 bit Ubuntu (and 64 bit Fedora previously). Cross-compiling on a 64 bit system shouldn't cause any problems. I've never noticed any in building the toolchain, cross-compiling the sdk and libs, or in cross-compiling significant programs (SNES9xTYL, Doom, Quake, etc).

I'd have to say the most common error people make in compiling for the PSP is forgetting the PSP uses cooperative multitasking. They expect a created and started thread to run on it's own, not realizing you have to call system functions that allow the thread to run before it will, even if it has a much higher priority than the main thread.

[snow]

Sorry, been gone for a week on vacation and I had started this thread to deal with an issue before I went away (and lacked internet access). The error had nothing to do with having a 64 bit OS. I had copied the following line from snes9xTYL into the snes9x 1.51 source that I'm trying upgrade to:

unsigned int __attribute__((aligned(64))) list[262144*4];

When I removed this the malloc/free issues went away. You'll have to forgive me if I can't immediately tell you why this was causing problems as I'm still newbish and I'm still learning the ins and outs of snes9x.

So in conclusion (or for those who found this with a search) COMPILING UNDER A 64 BIT OS HAS NO BEARING ON THE COMPILED PSP BINARY.