See, libf.so has now .init_array and .fini_array (together with .ctors and .dtors), but i have no printfs not from init/fini, not from ctros/dtors. Is is something to be deal in elf.library as well, or in newlib/clib2 ?
IIRC I read somewhere that someone did a nonsense change in elf.library which obviously can't work: Instead of the crtbegin/end C library startup code calling the constructor/destructor functions it's done by elf.library itself now, at least for .init/.fini_array. Before printf() and any other C library I/O function, but not limited to I/O but several other C library functions as well, can work the C library startup code (_start(), in newlib it IIRC should just call INewlib->_start() and most of the code is inside newlib.library and not in crtbegin.c) hast to be called, then the .init_array and .ctor functions. After the program exits, return from main() or calling exit(), first the .fini_array and .dtors functions have to be called and only after that the C library cleanup code.
If elf.library calls the .init/.fini_array and/or .ctor/.dtor functions instead of the C library crtbegin.c code you get the order 1. call constructor functions. 2. initialise the C library data required for example for printf() 3. main() 4. free the C library data required for example for printf() 5. call destructor functions which results in most C library functions, incl. printf(), can't work in constuctor and destructor functions.
To get working support for .init/.fini_array the code in elf.library calling those functions has to be removed and support for .init/.fini_array added in crtbegin/end instead. In case of newlib most of it in the INewlib->_start() function, just like for .ctors/.dtors.
@joerg So simple speaking, fini/init may work then already, and used instead of ctros/dtors, and that why we see no prinfs from ctors/dtors. But we also didn't have prinfs from fini/init because newlib/clib2 need to be updated. That correct ?
@all Is anyone aware if it possible to tell from command line to the gcc/linker to not create fini/init arrays, but only ctor/dtor ones ? (just to see, if ctor/dtor prints correctly still, and it's only fini/init fail to printf) ?
Just to be clear, I wasn't the one who made those changes . However, elf.library only calls constructors/destructors directly for dynamic libraries - not executables. It does this only instead of using the old __shlib_call_constructors/destructors mechanism.
Ok. The one thing I always have to check is that Timberwolf still starts up and unfortunately it is now crashing with the change I made regarding st_value. Need to do some more testing and checking as to why this is the case.
So simple speaking, fini/init may work then already, and used instead of ctros/dtors, and that why we see no prinfs from ctors/dtors. But we also didn't have prinfs from fini/init because newlib/clib2 need to be updated. That correct ?
With binutils using .init/.fini_array instead of .ctors/.dtors the only parts left in .ctors/.dtors in the executable should be the start and end pointers from crtbegin.c and crtend.c, i.e. empty {~0, 0} arrays, the constructor/destructor function pointers are in .init/.fini_array instead. To get the constructor/destructor functions in .init/.fini_array called crtbegin.c, crtend.c and newlib.library first have to be updated adding .init/.fini_array support, old and probably still current versions only call the functions in .ctors/.dtors.
Edit: According to Futaura the following is only correct for sobjs, not static linking. To check if the destructor functions are called already use IDOS->Printf() instead of printf(), or if IDOS->Printf() doesn't work either IExec->DebugPrintF(). If you get the output from the destructor functions that way even without updated C library parts binutils is working correctly but elf.library is broken.
For the constructor functions even IExec->DebugPrintF() can't be used because IExec is set up later in _start() in crtbegin.c if elf.library calls the .init_array constructor functions. You'd have to use the m68k zero page DSI exception handler to get a local sysbase from 0x4 and iexec from that first. Same as for destructors: If you get the constructor output binutils is working correctly but elf.library is broken.
With binutils using .init/.fini_array instead of .ctors/.dtors the only parts left in .ctors/.dtors in the executable should be the start and end pointers from crtbegin.c and crtend.c, i.e. empty {~0, 0} arrays, the constructor/destructor function pointers are in .init/.fini_array instead.
We tried to compile this test case we talk about (with prinfs() in sections) just for Linux, and the output is:
See, there printf() ok , and what more worry me : it's prints in the same time from both parts : and init/fini and ctor/dtors. I mean, one not exclude another or whatever happens there ..
Anyway,
Quote:
Edit: According to Futaura the following is only correct for sobjs, not static linking. To check if the destructor functions are called already use IDOS->Printf() instead of printf(), or if IDOS->Printf() doesn't work either IExec->DebugPrintF().
For first test, i just put everywhere IExec->DebugPrintf(), so test case are:
@kas1e With old binutils the constructor and destructor functions pointers are in the .ctors and .dtors sections, which is supported by both C libraries and the constructor and destructor functions are executed. With new binutils the constructor and destructor functions pointers are in .init_array and .fini_array instead, which isn't supported by any AmigaOS C library yet and none of the constructor and destructor functions can be called.
@joerg How you can explain that on Linux, its print from both init/fini and ctors/dtros from the same binary at the same time ?
@Oliver Quote:
Ok. The one thing I always have to check is that Timberwolf still starts up and unfortunately it is now crashing with the change I made regarding st_value. Need to do some more testing and checking as to why this is the case.
In the meantime, Max finds the place where comment out this "sym->st_value = 0;" to make it acts like older binutils : and it works ! This simple hello-world-from-sobj test case works even on 53.30 version of elf.library now!
Now we need to understand why on Linux we have prinfs from both fini/init/ctors/dtors from the same binary at the same time, and didn't have any printf when compile same for os4 : i.e. i understand what Joerg wrote, but if ctros/dtors is still there, it probabaly should acts like one Linux and printf at least from ctros/dtors as before , even if we have fini/init... But of course, if elf.library wasn't too much hacked in that terms, and when fini/init involved, it's no more use ctros/dtors (while on Linux seems that the case).
Edited by kas1e on 2023/9/27 20:55:57 Edited by kas1e on 2023/9/27 21:00:45
@joerg How you can explain that on Linux, its print from both init/fini and ctors/dtros from the same binary at the same time ?
The C library you are using on Linux, probably glibc but using for example a current version of newlib on Linux instead should of course work as well, includes support for init/fini and apparently still supports ctors/dtors as well. The old AmigaOS 4.x port of newlib and both AmigaOS 4.x clib2 versions don't support init/fini (yet) but only ctors/dtors.
but nothing for section(".init_array") and section(".fini_array") yet.
If you are still using dynamic linking for your tests first try to get static linking working, with an updated C library supporting init/fini of course, with the current versions it can't work. Only after that's working correctly the shared object parts should be tested.
@Joerg Yeah, i tried static linking of course firstly.
But what i tried to say is : If on linux both fini/init and ctor/dtors works at the same time (from the same binary), then, it kind of mean, that even if fini/init consturctors is not working because of our C libs, the ctor/dtors ones still should work, but (!) instead if we use binary from latest binutils, not only fini/init not works (that expected) but ctor/dtors also stop working, too.
What i mean is:
adtools: working ctor/dtor consturctors with both newlib and clib2 newbintuils: in the same binary we have now and fini/init and ctor/dtor, and while fini/init not print (expected), ctor/dtor also stop print (while should, if we compare it with how it on linux, when both fini/init and ctor/dtor prints at the same time).
But what i tried to say is : If on linux both fini/init and ctor/dtors works at the same time (from the same binary), then, it kind of mean, that even if fini/init consturctors is not working because of our C libs, the ctor/dtors ones still should work, but (!) instead if we use binary from latest binutils, not only fini/init not works (that expected) but ctor/dtors also stop working, too.
- crtbegin.o defines .ctors and .dtors with one element, -1 (0xffffffff on 32-bit platforms and 0xffffffffffffffff on 64-bit platforms).
- crtend.o defines .ctors and .dtors with one element, 0.
- crtend.o defines a .init section which calls __do_global_ctors_aux. __do_global_ctors_aux calls the static constructors in the .ctors section. The -1 and 0 sentinels are skipped.
- crtbegin.o defines a .fini section which calls __do_global_dtors_aux. __do_global_dtors_aux calls the static constructors in the .dtors section. The -1 and 0 sentinels are skipped.
Which means using init/fini instead of ctors/dtors doesn't support calling the ctors/dtors functions directly any more, but (for example on Linux) there are functions in .init_array and .fini_array in the C library which do that instead. Since our C libraries don't support init/fini at all yet there are of course no such __do_global_ctors_aux and __do_global_dtors_aux functions in init/fini, which seem to be required to call the old ctors/dtors functions.
As somewhere mention in the thread you referred to, it basically should go like that. If the value isn't 0 used that, else perform function address resolution. Lazy or not doesn't matter. How it should be done is even briefly/abstract described in the ABI. So you may "need" to read it to understand the code changes from elfpipe.
Thanks for that. It is just more difficult to understand because elfpipe's fix was not done correctly and was partially broken, causing seemingly random crashes.
I've adapted my fix to ignore R_PPC_REL24 relocs when st_value is 0, because it was originally ignoring R_PPC_PLTREL24 (for ldso version 1) when in fact those relocs do need to proceed as they originally did - this stopped Timeberwolf from crashing. I'm still not sure elfpipe's fix is quite right as it leads to duplicated lookups, but I'm hoping to resolve that if I can rewrite and cleanup the whole reloc handling routine.
Regarding binutils, you are correct that changing the code to zero st_value, as it should do, will be incompatible with earlier elf.library releases. It is a bit annoying that this "fix" was placed there, instead of fixing elf.library. The plan is to push an elf.library public update out once all reported issues have been resolved.
Which means using init/fini instead of ctors/dtors doesn't support calling the ctors/dtors functions directly any more, but (for example on Linux) there are functions in .init_array and .fini_array in the C library which do that instead. Since our C libraries don't support init/fini at all yet there are of course no such __do_global_ctors_aux and __do_global_dtors_aux functions in init/fini, which seem to be required to call the old ctors/dtors functions.
Oh, thanks, now it's clear. If we don't have working consturctor/destuctor in init/fini, we then don't have any calls to make .ctor/.dtors working (at least the way as it expected with init/fini), mean we don't have any output at all.
Probably the first thing is to make init/fini working, and then for sake of old support those do_global_ctors_aux/do_global_dtor_aux calls.
@Oliver Is support for .ctor/.dtor somehow hardcoded into elf.library ? Why i ask, because seems that for .ctor/.dtor we have proper support in newlib/clib2, but Alfkil back then add into elf.library some "init/fini" support : question is, is it the same as with .ctor/.dtor in elf.library ? If not, maybe it worth to be delete from elf.library, and instead should be added in newlib/clib2 ?
I think you are getting mixed up. There are two different situations - for executable programs, ctors/dtors are run by the clib2/newlib startup code - elf.library is not involved in that.
What Alfkil added in elf.library was for shared objects only - elf.library used to call __shlib_call_constructors and __shlib_call_destructors for shared objects, which in turn ran the ctors/dtors. Now elf.library doesn't call those functions and reads .ctors/.dtors itself and calls the functions directly. There is no startup code in a shared object as such (compared to an executable).
The .init_array/.fini_array handling in elf.library is again only for shared objects. For executables to support those sections, the startup code in clib2/newlib needs to be modified, as Joerg said.
Where can I find the old binutils elf32-amigaos.c file which has that dodgy patch in it? I need to read the surrounding code to understand exactly what areas it will affect, so I can handle it correctly in elf.library.
Where can I find the old binutils elf32-amigaos.c file which has that dodgy patch in it? I need to read the surrounding code to understand exactly what areas it will affect, so I can handle it correctly in elf.library.
I released a new beta version of elf.library (53.49) yesterday, which should now behave properly if st_value is 0 or not, for undefined functions. This doesn't include my rewrite of all the reloc code, as I've not completed that yet.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
. However, elf.library only calls constructors/destructors directly for dynamic libraries - not executables. It does this only instead of using the old __shlib_call_constructors/destructors mechanism.