binutils 2.40 first native(!) beta tests !

@All

So, with big and valuable help from MightyMax we were able to go till the moment that we have first _working_ native amigaos4 builds of binutils 2.40, which i test only in some "basics" tests such as:

1). creating of simple binaries
2). creating of binaries using sobjs
3). creating of .a archives
4). creating/testing bunch of test cases with all sort of different sobjs/binary and constructor/destrucotrs usage.

So far, that where we are with it, but your help as developer (not as user) is need it to betatest it too, to find out amigaos4 specific to native build bugs which or didn't happens on previous binutils from adtools and we need to recreate them, or , the bugs which you want to be fixed which wasn't fixed in old binutils as well.

Betatesting only for brave ones, and for ones who know what he do. There is first beta:

https://kas1e.mikendezign.com/aos4/bin ... _binutils_2.40_beta01.zip

It is expected that you do have latest GCC installed for being in sync (such as 11.2 or 11.3).

That how you need to test it:

1). rename your current SDK Dir to SDK_save
2). copy all the content of SDK_save to SDK dir again (so to have SDK dir with which you will play with, but having backup of it in SDK_save)
3). Unpack the content of the new binutils beta to the same directories as it in archive (i.e. to SDK/gcc/) of your SDK dir which you will use as tests.
4). reboot
5). test in the shell that you have new "as", "ld", and "ar" installed for sure, by typing in the shell "as -V", "ld -V" and "ar -V", it should show binutils 2.40 year 2023.

Now try to build your old projects with, etc.

Also, please, the ones who have skills (Joerg, Oliver, anyone else who had good skills about internals of amigaos4), plz take a look at the documentation Max and we tried to cookie up and if something is wrong about let us know plz :

https://github.com/AmigaLabs/binutils-gdb/wiki

It is really interesting reading and a try to summarize everything which wasn't ever documented anywhere about. Maybe someday it can fits into documentation or PDF of some sort once it will be good enough.

In the end of all we should thank Max working on all of this , and Joerg, Oliver and Frank for their valuable help with all of this !

Any issue you find, you can report there or directly on https://github.com/AmigaLabs/binutils-gdb/issues

Thanks!

That is a great achievement, MightyMax and Kas1e.
Thank you for all the hard work.

@kas1e

Im not home right now, but will give it a while once im able too.

Thank you very much for all the work

Great news, well done!

Recompiled FlashMandelNG 4,9 (all flavours versions) without errors.
A really fast test shows all runs ok but executables are about 10% bigger against latest SDK release (based on Walkero work).

GCC versions tested - 11,2.0 and 6.4.0

@flash

As a first report that sounds great. For the bigger files, I'm not sure where the root case for that is. If it is the ppc-amigaos specific changes, or general changes in binutils in the last years.

Great work!

I tried the new binutils + gcc-11.3.0 + clib4 with a number of small standard C programs without any issues. I did not check if the file sizes, though.

Thanks for the update. Unfortunately, my problem with the manual execution of the clib2 constructors and destructors still persists with the new binutils. I've posted a short sample program that demonstrates the issue here: https://forum.hyperion-entertainment.com/viewtopic.php?f=26&t=4964

I've tried to compile the sample program with gcc 11.2.0 and kas1e's latest binutils but it still crashes. The address is somewhat curious though: Grim Reaper reports the address as 0xc0defacc ....

@softwarefailure
Your _fini(void) function can't work because int j (why static?) isn't initialized to 0 and therefore __DTOR_LIST__[j+1]() may be a random memory address and not a destructor function pointer from __DTOR_LIST__[].
Additionally it may try to call one function too much, i.e. the NULL pointer from crtend.o at the end of __DTOR_LIST__[], but I'm not sure.

Quote:

As per the C standard, static variables are auto-initialized to 0 so it's not necessary to explicitly initialize them to 0. Nevertheless, I've just tried to initialize "j" to 0 explicitly but unsurprisingly this doesn't make a difference and the program crashes in the very same way with an instruction fault at address 0xC0DEFACC (sic!)

As to why "j" is declared static, no idea. As I said in the thread over at the Hyperion forums I took this code straight from clib2. It's the standard clib2 constructor/destructor (de)initialization code so I don't think there's anything wrong with it.

According to afxgroup's reply on the Hyperion forums it's a bug in the binutils which don't NULL-terminate the ctor/dtor lists on linking, thereby causing invalid ctors/dtors getting called. That's why I was hoping the latest binutils would fix the issue but it's still there :(

@softwarefailure
Quote:If you take any function from the clib2 sources you can be 80% sure it has a serious bug
That was one of the reason it was replaced more than 20 years ago by newlib...

Quote:That's utter nonsense, unlike for .init/.fini it's not the job of binutils to terminate the .ctors/.dtors array with a NULL pointer, you have to do it yourself (it's of course automatically done when using the standard C library startup and linker script)
crtbegin.c/o or in your case child.c/o:
crtend.c/o:
If you don't link with crtend.o, or custom code with the same contents, as last object file that's the reason for the missing NULL-termination of .ctors/.dtors.

Oh man, thanks a lot, you're my personal hero. Looks like amigans.net is the place to turn to now when having problems with the SDK. I've been on this for months and asked several people and was repeatedly told even by SDK team members that it's binutils fault and "there is nothing you can do about it at moment" and they were working on new binutils. But apparently all I need to do is manually including crtbegin.o and crtend.o on the link line. So I'm linking like this now:



This works nicely so once again thanks a lot for your help!

@all

So, i tested a full ScummVM build with binutils 2.40 and while it compiles fines it somehow breaks at linker stage:




The binary gets linked but crashes (right now, maybe it silently exits if i tweak the code a bit, need to test, but there is definitely something wrong)

sorry

@Raziel

Confirmed with a fresh build and minimum engines...ld has a bug in it's 2.40 incarnation

@Raziel

Did you even re compile all the used libraries, like libvpx.so ?

And if you start the program, do you get a GR, and if yes, can you give me the generated stacktrace?

@MigthyMax

I need to recompile *all* used dependancies???
Those are third party libraries, i didn't even know where to start...some of them are pretty old already


Here you go...

@Raziel

Quote:

No, I just was wondering if you did.

@MigthyMax

Phew, you got me sweating there

@Max
On the http://sourceware.org/bugzilla/show_bug.cgi?id=25135 , binutil's authors point out it was an issue in binutils in 2019, and were then fixed. I assume it should be in 2.40 as well , as it were released in 2022-12-31 ?

They also point out this kind of warnings are harmless, and have no impact on creating a binary, so, maybe crash in the binary Raziel have is different inssue, not related to those warnings (through, still strange , why he still have them, if it was fixed in 2019?)

@Raziel
Can you double-check if you indeed use all the new binutils (and ld, and all other stuff) ? Do you run it from makefile how, like "ld" , or like "ppc-amigaos-ld" ? And if so, if you run it from pure amigaos4 shell, or from "sh" in amigaos shell ? What i mean, can you mimic the same environemnt , and then in it type "ld -V" , "as -V" and "ar -V" , so we will 100% sure that all of the binaries takes by Scummvm's path are taken of the proper-new versions ?

@kas1e

There *is* indeed still a problem inside ScummVM, which I haven't had the chance to test thoroughly yet.

I will do so once I get back home.

I'll also try to give feedback on all your pointers, then.

There is a slim chance that the 2.40 based binary, instead of crashing immediately, simply exited and in turn caused the crash mentioned above, but either way, it shouldn't crash or exit in the first place.

Please bear with me while I don't have access to my gear.

And thank you all for taking the time