@all Just to let you know, Max did fix "default strip behaviour" of new binutils, so it reacts the same as adtool's one (same size after default strip as adtools version). But it's even a little better: adtools version for unknown reasons remove after stripping from .rela.text section an "I" flag which original binary had, as well as regroup for no reassons string header sections. Our new one dind't do that, and keep it as it should be, but only strip.
But I#m bot sure if it even still strips unneeded reloc or just keeps everything to be sure.
The strip from binutils 2.14 kept all relocs, incl. unneeded ones. I built my own "stripreloc" tool to remove unused/no-op relocs, for example 16 bit r13 relative _SDA_BASE_ ones, from the executables when using ld. Not 100% sure anymore, but IIRC vlink does remove unused relocs.
@MigthyMax When ld creates an executable (ELF EXEC) it resolves all relocs and for example on Unix all relocs are removed from the executable (at least when static linking, may be different if shared objects/linking is used). On Unix that's possible because ld knows to which memory address the executable will be loaded later: The VirtAddr in the program header.
On AmigaOS it's different, elf.library allocates pages for the executable and has to re-relocate it from the VirtAddr in the executable to the (random) memory address it was loaded to, and for that the relocs still have to be in the executable. But it's only required for absolute relocs.
Relative relocs like the small data r13/_SDA_BASE_ ones are accessed as "r13 +/- offset" and the offset is always the same, no matter where in memory the _SDA_BASE_ (middle of .sdata and .sbss) is in memory. It's the same for relative relocs in the code, for example if there is a "bl PC + 12340 bytes" function call it's always the same no matter where the .text section is in memory. Such relative relocs can be removed.
It turns out that in new version of LD we have a crash when trying to build any binary with .so attached to it. Even if we didn't use -use-dynld, but just add -L/dir_with_libs and -l<lib> , it makes linker to take firstly .so version of libs as expected, and that cause LD to crash. Builds with *.a versions didn't crashes.
Adtool's version of LD of course handle both cases correctly, so we seem missing something in terms of all this .so / dynld support in new LD
I tried to "gdb" it, and that what i have:
$ gdb -q --args ppc-amigaos-ld.exe test.o -o test -L/usr/local/amiga/ppc-amigaos/SDK/clib2/lib /usr/local/amiga/ppc-amigaos/SDK/clib2/lib/crtbegin.o /usr/local/amiga/ppc-amigaos/SDK/clib2/lib/crtend.o -lc
Reading symbols from ppc-amigaos-ld.exe...
(gdb) run
Starting program: /usr/local/amiga/bin/ppc-amigaos-ld.exe test.o -o test -L/usr/local/amiga/ppc-amigaos/SDK/clib2/lib /usr/local/amiga/ppc-amigaos/SDK/clib2/lib/crtbegin.o /usr/local/amiga/ppc-amigaos/SDK/clib2/lib/crtend.o -lc
[New Thread 3288.0x17ec]
[New Thread 3288.0x2310]
[New Thread 3288.0x1b90]
[New Thread 3288.0x15d8]
Thread 1 "ppc-amigaos-ld" received signal SIGSEGV, Segmentation fault.
0x0000000100436392 in bfd_putb32 (data=<optimized out>, p=0x48) at ../../bfd/libbfd.c:836
836 addr[0] = (data >> 24) & 0xff;
(gdb)
(gdb) bt full
#0 0x0000000100436392 in bfd_putb32 (data=<optimized out>, p=0x48) at ../../bfd/libbfd.c:836
addr = 0x48 <error: Cannot access memory at address 0x48>
#1 0x0000000100445356 in write_global_sym_plt (h=0xa00025fc0, inf=0x10056f7e0 <link_info>) at ../../bfd/elf32-ppc.c:9744
val = <optimized out>
rela = {r_offset = 16844960, r_info = 4299380317, r_addend = 0}
loc = <optimized out>
reloc_index = <optimized out>
plt = 0xa000ab3c8
relplt = 0xa000ab4f8
dyn = <optimized out>
info = 0x10056f7e0 <link_info>
htab = 0xa00025650
ent = 0xa000ad7c8
doneone = <optimized out>
#2 0x0000000100437aaa in bfd_link_hash_traverse (htab=htab@entry=0xa00025650, func=func@entry=0x100445250 <write_global_sym_plt>, info=info@entry=0x10056f7e0 <link_info>) at ../../bfd/linker.c:671
p = 0xa00025fc0
i = 195
#3 0x0000000100453caa in elf_link_hash_traverse (info=0x10056f7e0 <link_info>, f=0x100445250 <write_global_sym_plt>, table=0xa00025650) at ../../bfd/elf-bfd.h:787
__PRETTY_FUNCTION__ = "elf_link_hash_traverse"
#4 ppc_finish_symbols (info=0x10056f7e0 <link_info>) at ../../bfd/elf32-ppc.c:9813
htab = 0xa00025650
ibfd = <optimized out>
#5 0x00000001004224da in ppc_finish () at ../../ld/emultempl/ppc32elf.em:239
No locals.
#6 0x000000010041547f in lang_process () at ../../ld/ldlang.c:8210
No locals.
#7 0x00000001004da16c in main (argc=<optimized out>, argv=<optimized out>) at ../../ld/ldmain.c:497
emulation = <optimized out>
start_time = 15000
flags = <optimized out>
(gdb)
A full stack-backtrace in GDB shows some strange 0x48 address of memory when we call bfd_pitb32(), but then it comes from write_global_sym_plt() , meaning that we mess something when tries to write things to the elf-binary when .so in use ?
Edited by kas1e on 2023/8/19 19:50:31 Edited by kas1e on 2023/8/19 19:55:48 Edited by kas1e on 2023/8/19 19:59:25 Edited by kas1e on 2023/8/19 19:59:47 Edited by kas1e on 2023/8/19 20:03:08
Even if we didn't use -use-dynld, but just add -L/dir_with_libs and -l , it makes linker to take firstly .so version of libs as expected, and that cause LD to crash. Builds with *.a versions didn't crashes.
Probably not related to the crash, but on AmigaOS -static has to be the default mode for ld which doesn't use .so but only .a libraries. Maybe something is wrong in the (internal) specs file.
Issue #6: Using .init_array/.fini_array instead of .ctors/.dtors requires changes in the C libraries, maybe even in elf.library.
Issue #6: Using .init_array/.fini_array instead of .ctors/.dtors requires changes in the C libraries, maybe even in elf.library.
Regarding the constructor/destructor change, is it just a simple modification in crtbegin and crtend? After all, it's just a list of pointers that get called if I'm not mistaken.
If we start using the .init_array/.fini_array, we need to add a priority parameter. But other than that, it should be simple, or am I overlooking something?
edit:
I played a little around with gcc and the linker.
it looks like we need an update too adtools as I could not get gcc or the linker use .init_array's..
I tryed with a test source to create .init_array/.fini_array instead of .ctors/.dtors elf sections with this
Regarding the constructor/destructor change, is it just a simple modification in crtbegin and crtend? After all, it's just a list of pointers that get called if I'm not mistaken.
For statically linked executables it's only the code in crtbegin and the first (~0/-1) and last (NULL) pointers in crtbegin and crtend, but for executables using shared objects elf.library probably has to be changed to add support for .init_array/.fini_array.
@rwo Just in case you didnt read whole thread and didnt know where we are: in adtools we already have gcc 11.3, and even latest SDK have it if i remember right.
Also in Max's repo (from where links on tikets are) we exactly fixing latest binutils from 2023 (and they already works, just some issues mentioned above to fix).
I.e. i already use gcc 11.3 + latest binutils from Max, everything fresh in other words.
And init-fini issue is that what we try to fix: it didnt works before , and now, when new binutils and gcc in place want to make this one to work too.
Ps. Adtools repo its both binutils(as,ld, strip, etc) and gcc (gcc, g++, cpp, collect, etc). While gcc part in adtools are up2date already, binutils one were too old, and new one in Max repo. So you build gcc from adtools, and binutils from max, and mix it all in one place.
and to add to as1e answer, you should probably even use the clib from afxgroup. Because if a c library can handle fini_/init_array than that one.
Except for several bugs in the clib2 versions of crtbegin.c and ctrend.c, which the newlib versions don't have, and opening newlib.library instead of clib2.library, the newlib versions of crtbegin/end are basically the same as the clib2 ones, incl. that both have no support for .init_array/.fini_array.
Except for several bugs in the clib2 versions of crtbegin.c and ctrend.c
Do you remember which ones ? Pretty possible Andrea already fixed them all
Quote:
Probably not related to the crash, but on AmigaOS -static has to be the default mode for ld which doesn't use .so but only .a libraries.
At least all i can say, is that in Adtools version, if you just do -L<diretory_with_libcs> and -l<lib> at end of compiling line, then, LD will firstly take any .so which find with that name. And if no .so find, then will use .a file. At least that how it for long already. Of course it easy to swith to -static builds to be default (so to not link against .so firstly, but against .a, and only link with .so , if --use-dynld used), but maybe when adtools version were created there were reassons for ? Or just simple mistake ?
Quote:
Maybe something is wrong in the (internal) specs file.
Currently, what i find, is that any try to link against .so library (be it even test.so with 0 bytes of size), our new LD crash. I.e., it doesn't matter what inside of .so file, the matter is the fact that you link against .so. Even if you just do something like:
ppc-amigaos-gcc -o test test.c -L. -lf -athread=native
Where in root dir you have libf.so of 0 bytes of size : we still crash. Like, once we involve usage of any .so, this trigger the way of handling dynamic linking , and when start constructing elf file died.
it does not close libraries, after being opened, if programs calls Exit(0); perhaps.
Should it setup pr_ExitCode and pr_FinalCode ?
Alert() is not multitasking friendly, perhaps should not be used, but if DOS can't be opened, then perhaps, something else is really wrong, so maybe not, actually a bug.
Perhaps there should be shadow IFace for etch library opened, as there no guarantee, that application has not set the pointer to NULL, before exit. and so it might not be closed twice. if it was opened twice by accident.
(Most applications do not know if Interfaces are valid, when program starts, but some indications that it should not be opened is given when the compiler will give, error about interface/base being defined elsewhere. But I think it should be more failsafe than that.)
Edited by LiveForIt on 2023/8/21 22:07:40 Edited by LiveForIt on 2023/8/21 22:31:41
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
newlib doesn't use the same clib2 mechanism for constructors. newlib doesn't have CONSTRUCTOR defines that clib2 (original too) has. If you try to change the clib2 crtbegin/end files trying to change .ctors/.dtors to ~0/1 nothing will work with current gcc (don't know the ancient version of 20 years ago). If you think that this can be fixed of course feel free to send a pull request That's the beauty of open source
@LiveForIt
Libraries are always closed correctly inside clib2 function that call main because exit will jump into longjmp that will call the routine that will close the libraries, call the destructors and so on. Why setup and use pr_ExitCode and pr_FinalCode? I'll fix the closing routine that will set the pointers to NULL.
Instead of using the sysbase pointer from the _start() arguments he is intentionally causing a DSI exception to get the SysBase from the DSI handler, which is only there for emulated m68k software, and might be a different SysBase.
Maybe he is trying to prevent software using his clib2 versions from working on multi-core kernels? At least I can't think of any other reason for using nonsense like that.
But that's not the only one, there are more bugs in it...
idltool generates that in all AmigaOS4 libraries. So perhaps we need updated idltool then?
Why is it a problem to have exception on multicore? The exception handler can FindTask(NULL), and figure out what core its running on, from maybe process or task structure perhaps.
DSI exceptions does not break forbid, and FindTask(NULL) does not need a forbid.
There is function in exec that allows you check if you’re in forbid or not, so you can determine if it's required or not, while you’re in the exception.
Sure unnecessary exceptions are bad, as it will slow down the system, but only good tools and guidelines will resolve that
Edited by LiveForIt on 2023/8/22 22:58:24 Edited by LiveForIt on 2023/8/22 22:59:22
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
@All Today build latest EUAE with new BinUtils from Max, and so far all good. So currently what i build with new binutils is SSHTerm and E-UAE : both binaries working.
Through, need to note, that E-UAE by some reassons do have "-Wa,--execstack" in all the makefiles, causing new binutils to spawn a warning which authors of binutils added recently (since v2.39):
Quote:
The ELF linker will now generate a warning message if the stack is made executable. Similarly it will warn if the output binary contains a segment with all three of the read, write and execute permission bits set. These warnings are intended to help developers identify programs which might be vulnerable to attack via these executable memory regions.
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
Donate
