Exceptions cannot be caught

[Midar]

I finally figured out why since some updates ago (I suppose it's about a year now), all I get is "Program aborted": It seems that catching exceptions no longer works and they just result in "Program aborted". I suppose this is related to the changes in how frames are registered, but I haven't bisected it yet.

This happens without using a .library, so it's not the .library being at fault here in how it registers EH frames.

[hitman-codehq]

Hello @Midar, there were some problems with exceptions in a previous version of Bebbo's GCC, and you can see that there was a long conversation here:

https://github.com/bebbo/amiga-gcc/issues/218

There is a attachment in that issue (Exceptions.zip) which contains some test code. Interestingly, both of the test cases inside that code are now broken.

So it seems that it's back. So which change introduced it...

[hitman-codehq]

@bebbo I looked back in the history to November last year (when I last build a working version of the compiler) and I can't see any changes that would obviously cause exceptions to stop working. The only thing that might make a difference is a change to libamiga.a. Debugging this is a bit beyond me.

[bebbo]

exceptions did work on 10th of April with libnix and do work with newlib too now.

[hitman-codehq]

@bebbo the problem is that I use clib, not libnix or newlib. Do you remember what change caused the problem?

[bebbo]

@bebbo the problem is that I use clib, not libnix or newlib.

Oh ... I'm so sorry. You have to add the cxxglue.o which can e.g. be found in libnix: /build-Linux-m68k-amigaos/libnix/lib/nix/cxxglue.o.

Do you remember what change caused the problem? No - I don't test the clib2 c++ combination. The problems here seem to be caused by

• no longer adding cxxglue.o to the provided input files, now the symbol ___init_eh is wanted. Nothing in clib2 provides that atm.
• stabs/constructors were replaced with sections. clib2 got updated accordingly.

[bebbo]

added cxxglue.c to the clib2 too

[hitman-codehq]

added cxxglue.c to the clib2 too

Thanks! I guess that's not pushed to GitHub yet?

[hitman-codehq]

BTW @bebbo I am experimenting with using libnix instead of clib2. Can you confirm that the way to do this is to specify -mcrt=nix20 both when compiling and when linking? I want to make sure I'm doing it correctly.

I remember seeing some instructions on your GitHub page a while ago, but I can't find them now.

[bebbo]

added cxxglue.c to the clib2 too

Thanks! I guess that's not pushed to GitHub yet?

it's live: https://github.com/bebbo/clib2

[bebbo]

BTW @bebbo I am experimenting with using libnix instead of clib2. Can you confirm that the way to do this is to specify -mcrt=nix20 both when compiling and when linking? I want to make sure I'm doing it correctly.

I remember seeing some instructions on your GitHub page a while ago, but I can't find them now.

You always add it to compile an link once. Ensure that it doesn't appear twice at the linking stage.

[hitman-codehq]

Thank you for the tips! I can confirm that after rebuilding with the latest amiga-gcc repo version and the new clib2, the exception handling is working again.

[hitman-codehq]

Actually I am having some trouble with getting my software to work with -mcrt=nix20. My libauto.a entry points are crashing. @bebbo you may remember this issue from last year:

https://github.com/bebbo/amiga-gcc/issues/289

We had some problem the the following code:

void OpenAslBase() attribute((constructor));

void OpenAslBase() { AslBase = SafeOpenLibrary("asl.library"); }

Should this be working with -mcrt=nix20? The code is crashing hard at startup and it seems that the functions like OpenAslBase() are not actually getting called - the crash happens in the C++ startup code. With -mcrt=clib2 it is working.

[bebbo]

It looks like some library couldn't be opened. The init code could crash if the dos.library wasn't already opened... this is fixed now.

attribute((constructor)) does work

[Midar]

Sorry for the late response, I finally have working computer again now.

Unfortunately nothing has changed, abort() gets called immediately. The usual failure mode was that exceptions just aren't caught, but it seems in this cases just entering a try block is already aborting everything?

// Edit: @try itself works, the abort()is on the first @throw. It just turned out there was a @throw during startup already.

[Midar]

Debugged it: It's the same problem again. m68k-amiga-gcc doesn't link in the glue any more, only m68k-amiga-g++ does. This is the same issue as a few years ago.

[hitman-codehq]

@Midar I have had similar problems in the past, due to using gcc instead of g++, so it's important to use the correct compiler front end if you are targeting C++.

Another "gotcha" that caught me out is that you have to use the same compiler switches for all .cpp files that you are building. I have one file in my support library (a BSD socket wrapper class) that uses C++ exceptions, so I was enabling exceptions just for that file, to try and make my executable smaller. But this meant that on some C++ compilers, exception handling was broken! It has to be enabled for all files to work properly.

Actually, using C++ exception handling for one single file has caused so many problems that I regret using it! Plus it has made all of my binaries larger.

[Midar]

@hitman-codehq m68k-amigaos-gcc would be the correct compiler for ObjC with exceptions, though.

[bebbo]

you could have used the option -Wl,-u___init_eh ...

[Midar]

Ah, good idea! That works, excellent!

[bebbo]

giving -fexceptions to the linker via gcc does the same now.

[Midar]

Thanks, that brings it back to the old behavior - I could revert all hacks now.