forums.ps2dev.org

stefan · Joined: 14 Nov 2004 Posts: 10

What would it take to get fully functioning C++ support in GCC 3.2.2? I remember reading about crt0.s needing to call _init(), which seems easy enough to fix, but are there any other problems in the toolchain?

You don't have to be a toolchain hacker to respond, if you develop on PS2 using C++ and have run into problems please post them here. I'm willing to look into the major roadblocks so that we can have a robust C++ toolchain.

Thanks :)

pixel · Joined: 30 Jan 2004 Posts: 791

About _init and _fini, those should be internal symbols only. That is, the usual crt mess from gcc/glibc is modular and comes in multiple files. A module file (.so under linux) may provide _init and _fini symbols, and when compiling a .so file, it will use some other crt modules providing these symbols as weak. Now I may be wrong, of course. That is such a mess ;) Well, we may try to introduce them if "really necessary" (that is, if somebody exhibits me some code which is really needing that _init symbol to be called). Well, anyway, that's not a big issue to implement... Only having to call _init and _fini in our crt0, and provide them as weak symbols into crt0.o.

IMHO, the biggest issue to support "full" C++ is the STL which requires alot of libc support. And I am one to be willing to definitively get rid of newlib's libc (I think libm may stay). Now, I don't really like STL too, and I have no idea about the problems linked to missing libc functions to our ps2sdk's libc when using STL. I think it should require "full" stream support (we are lacking the unputc functions), but apart of that, I don't know ;)
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

mrbrown · Joined: 17 Jan 2004 Posts: 1536

_init() and _fini() are used to initialize global/static constructors and call global deconstructors in C++, so they are definitely required for "proper" C++ support. GCC also has an extension for C, where you can use the function attribute "constructor" to register a C function to be called automatically at program startup. That seems like it could be useful.

If I were adding calls to _init() and _fini() in crt0, I'd make sure I didn't break compatibility with other toolchains that don't use the _init/_fini system (e.g. the 2.9x EE toolchain). IMO, they must be added, because asking C++ developers to call _init() at the top of main() exposes parts of the compiler the developer shouldn't have to know (or care) about, and it's silly to ask such a thing when the fix is obvious. Just make sure it's a clean fix.

If you are going to be using C++ on PS2, then I strongly advise against using STL for anything. STL has the nasty habit of allocating objects behind your back, and besides GCC 3.2.2 isn't terribly efficient at removing duplicate template instantiations (IIRC) so you could end up with horribly bloated code. If you really do need STL I'd recommend using STLport.

Anyway, those are the only C++ issues I know of. It's also advisable to compile without exceptions (-fno-exceptions), as including them without using them can generate unwanted references to GCC's internal libraries. Using -fno-rtti is a good idea too (if you are trying to use dynamic casts in C++ on PS2, then you're using "too much" C++).

IMO besides the issues mentioned above, C++ support is already solid in GCC 3.2.2.
_________________
"He was warned..."

Lukasz · Joined: 19 Jan 2004 Posts: 248 Location: Denmark

Here is my solution to the global constructors fix or non dynamic created classes as N!K would say.

I came up with this since _init() was just a jr ra, nop function, maybe that is fixed now, posting it even so :)

In my link file I've put in ctors and dtors as shown below

pixel · Joined: 30 Jan 2004 Posts: 791

mrbrown · Joined: 17 Jan 2004 Posts: 1536

It's in crti.o (or crtbegin.o), which is in GCC (gcc/config/mips/crti.asm and gcc/crtstuff.c).
_________________
"He was warned..."

pixel · Joined: 30 Jan 2004 Posts: 791

Damn me... why haven't I thought of it.
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

Guest · Posted: Wed Nov 17, 2004 1:17 pm Post subject:

stefan · Joined: 14 Nov 2004 Posts: 10

Ok.

I have checked in support for C++ global/static constructors and destructors and in the process exposed a problem in how ps2sdk linked programs. First off, the change I made to crt0.s should be backwards compatible with older EE compilers if someone is still using them.

The problem was that ps2sdk used -nostartfiles in its Makefiles (Rules.make) when doing the final link of a program. This prevented crtbegin.o, crti.o, crtend.o, and crtn.o from being linked with the program. These files hold the magic of the static constructors. This is why Lukasz only saw _init() as jr $ra (I think).

Anyway, the result of me fixing that (using -mno-crt0 instead of -nostartfiles) means that normal C programs will now have .ctors and .dtors and also the _init()/_fini() magic. Note however that GCC supports static constructors and destructors in C, if you use the attributes that mrbrown mentioned (see the GCC manual). Those sections can be easily stripped from your executable, if you aren't using them (see ee-strip --help).

The only other weird thing right now is that the linker puts the destructor code before _start(). I tried a few things but couldn't fix it, but I'll get it sorted out soon enough. Please let me know if you have any problems with what I've checked in. I'd also like feedback from C++ users: get rid of the current _init()/_ctors() hack and let me know if it works for you. Thanks.

mrbrown · Joined: 17 Jan 2004 Posts: 1536

Excellent work, stefan.

Note that stefan completed what MrHTFord started when he added support for _init and _fini to GCC 3.2.2. And if you don't like the extra sections, remember that in GCC 2.9EE instead of _init there was __main(), which was called at the top of main() regardless of whether or not your program was C or C++, or whether or not you had any global constructors. stefan's change only adds a few more bytes but brings the tools back into the state they were before I butchered them and MrHTFord started to fix them :P.

Now why did it take so long for someone to fix this?
_________________
"He was warned..."

mrbrown · Joined: 17 Jan 2004 Posts: 1536

Sorry, one last thing: You can still specify -nostartfiles if you don't want any of the _init/_fini stuff. Just add it to EE_LDFLAGS in your Makefile.
_________________
"He was warned..."

blackdroid · Joined: 17 Jan 2004 Posts: 564 Location: Sweden

ooPo · Posted: Tue Nov 23, 2004 9:32 am Post subject:

yea and verily

rasmus · Joined: 21 Jul 2004 Posts: 17 Location: G�teborg, Sweden

The constructors and destructors are working very well for me now, thanks a lot Stefan!

The only thing I noticed is that static objects at function-level does not get destructed at all, ie

mrbrown · Joined: 17 Jan 2004 Posts: 1536

mharris · Joined: 25 Jan 2004 Posts: 155 Location: Annapolis, MD, USA

radad · Posted: Tue Nov 23, 2004 2:48 pm Post subject:

mrbrown · Joined: 17 Jan 2004 Posts: 1536

A note about calling exit() or returning from main() normally (without SleepThread()): At some point pukklink, and thus ps2link, was fixed up so that ps2link would handle a program falling off of main(), or one that called exit(). In the _exit() routine in crt0.s, there is cleanup code for the case where the program was executed by ps2link. This is also where stefan added code to call _fini() which will call global destructors. Because ps2sdk's libc exit() calls _exit(), global deconstructors should be called normally.

The other thing to consider is how your app will run. If you're writing a game or emulator or something along those lines, then you know you'll be running until the user hits reset. So there's never really a need to clean up behind yourself. But maybe one of these days someone will come up with a smooth way for apps to return to their parent, so that all of these ELF loading utilties that keep cropping up can execute a program and expect for it to clean up after itself before returning control to the loader.

I guess what I'm trying to say is IMO it's always a good idea to clean up after yourself. SleepThread() at the end of main() has been obsolete for some time now. :P
_________________
"He was warned..."

rasmus · Joined: 21 Jul 2004 Posts: 17 Location: G�teborg, Sweden

I am sorry if I was unclear. I didn't expect x to be destroyed when the function exits, but when the program exits. A global instance of Bar is destructed properly after main() with Stefan's fixes. x does never get destructed though.

Please see this test program:

mharris · Joined: 25 Jan 2004 Posts: 155 Location: Annapolis, MD, USA

Hmm, I've seen odd stuff before when trying to trace global dtors -- since it's happening after the program ends, all bets are off. I ran into trouble a while ago on some unix machine where stdout was closed before the global dtors ran (so everything was actually working OK, it just ate my debug output).

I'm not saying that's the problem -- in fact it's probably not, since you're getting Bar::~Bar(1) in the output. But be aware that weird things can happen after program's end...

cheriff · Regular Joined: 23 Jun 2004 Posts: 262 Location: Sydney.au

Hey c++ ppl!
I'm trying to move some cpp code onto ps2 and it does use <vector>. I link against stlport and all seems fine. Untill I try to instansiate a class (thats has all methods implemented inline in the .h, if it makes a difference):

At the global scope:
myClass thingy;
is the line that does it. removing this and it compiles and links no worries.

this one line spews forth a barrage of undefined references:setlocale, __assert, _impure_ptr, atoi, mcSync. Even sscanf, when i don't use it myself.

the link command is:

pixel · Joined: 30 Jan 2004 Posts: 791

First, consider using stlport. Second, some functions are indeed not defined, such as vsscanf, or setlocale. Just write stub functions for them, that'll do it for now...
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

cheriff · Regular Joined: 23 Jun 2004 Posts: 262 Location: Sydney.au

Thanks, i finally got it. I wasn't linking against libg. My link command:

pixel · Joined: 30 Jan 2004 Posts: 791

"libg" is the debug version of newlib....... you just didn't read what I said earlier.

oh, well, after all, nevermind.
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

mrbrown · Joined: 17 Jan 2004 Posts: 1536

Actually libg is the exact same thing as libc. Some weird fruity GNU thing. I guess it's convenient when ps2sdk has a library called libc as well.

pixel · Joined: 30 Jan 2004 Posts: 791

I thought it was "the-same-but-built-without-O3", but it obviously seems I was wrong. Exactly the same binaries. *shrug*
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.