While MightyMax trying to bring for us latest binutils, we stopped on the moment of the needs of elf32-amigaos.c file as in current adtools's binutils.
Checking the file, we find out that this is just pure copy of the elf32-ppc.c original, just with some additions on top in terms of BREL relocations support.
Question is : are those BREL relocations used at all in the current amigaos4 binaries, or in OS4 at all ? Is it still require it ? Will OS4 binaries works without, or, more precisely, will we have any issues if we will not worry about BREL relocations support ?
It will be just clean and cool to use original elf32-ppc.c file, without too much additional patch work on top.
@kas1e BREL support is required for re-entrant executables which can be pre-loaded with C:Resident, or by setting the 'p' and 'h' protection bits (pure + hold, and no, the 'h' bit never was anything like "hidden" on AmigaOS, just misused that way by some broken tools like DOpus), using different (IIRC R2 based) data for each instance. No idea if it's still used, but for example most shell commands in C: used it.
@kas1e Only software built with -mbaserel uses it, not any software built without it, but removing support for it from GCC or binutils would be a very bad idea.
I thought the gcc -mbaserel option was (for amiga is) just a relative addressing mode. Similar to the .sbss in the ABI but using r2 as base pointer. And for .sbss and -baserel, that the common PPC relocations from the ABI are sufficient. But it seems the -mbaserel gcc option on the amiga gcc does even use the PPC OS4 BREL specific relocations?
Joerg do have a simple c example which result in emitted BREL relocations ?
haaa , so it means, that we do not have working baserel support for _many_ years, and mostly no one noticed :)
Before checking the AmiSSL makefile I didn't even know there was a working GCC 4.x version, if it was available at all for AmigaOS 4.x and not only as cross-compiler. IIRC the last one I used was a GCC 3.4.x version, and even that only for some C++ code which didn't work with GCC 2.95.x, for example some parts of OWB. Everything newer was either only available as cross-compiler, or had too much bugs (for example 4.3.x) for my AmigaOS 4.x software 🤷♂️
Additionally for native AmigaOS 4.x software I usually used vlink instead of ld because I got better results with it.
@MigthyMax Quote:
Wouldn't it not even be possible to use the sbss data model to achieve the same result (aka useful for re-entrant executables)?
-mbaserel uses a special C library startup in the baserel directory which creates a copy of the data and bss and uses that for the current instance instead of the data and bss in the executable, making it possible to run multiple instances using the same code but different data at the same time. -msmall-data uses the same crtbegin.o as not using -msmall-data which doesn't create a copy of the sdata/sbss. IIRC the r13 based -msmall-data model has some size limit on data and bss, which the r2 based -mbaserel doesn't have.
Edited by joerg on 2023/8/9 20:22:17 Edited by joerg on 2023/8/9 20:23:15
If you clone that repository, it can be a matter of running
./adt -b && ./adt -t
To have the script automatically build a cross compiler (locally, within the directory used for the clone), and use that built compiler to generate all of the tests. The final LHA file can then be copied to the AmigaOne machine and a single script can run all of the tests and report the status of each back.
If you already have a cross-compiler on your machine and ppc-amigaos-gcc is on the path
./adt -u -t
There are lots of other options so you can check the README or just run ./adt. But, I am using this general script to help build a number of cross compilers, applying changes, and running tests again.
If liberty means anything at all, it means the right to tell people what they do not want to hear. George Orwell.
-mbaserel uses a special C library startup in the baserel directory which creates a copy of the data and bss and uses that for the current instance instead of the data and bss in the executable, making it possible to run multiple instances using the same code but different data at the same time. -msmall-data uses the same crtbegin.o as not using -msmall-data which doesn't create a copy of the sdata/sbss. IIRC the r13 based -msmall-data model has some size limit on data and bss, which the r2 based -mbaserel doesn't have.
Ok, so -baserel is more in direction to how TLS works on other OSes. Each instance get its own data and bss section. Probably only the bss section, because the data section contains the program code, which should be re-entrant, so can be shared?
What do you mean with instance?
I don't get it how it works/worked. An executable gets loaded by the elf library, and the elf.library set ups the initial task for the executable. The initial task executes the special C library startup code and setup the baserel stuff. If the executable gets started a second time. Nothing is shared from the first run, hence two complete disjoint setup even being the same program.
The only setup I can come to mind is a amiga library. Which gets executed by multiple task simultaneously, and each task would have its own parameter/variable memory block. But that must be somehow setup by the library during opening.
So for me it still more or less the same, except the used register, and maybe the baserel has no size limitation. But I'm not sure about that.
Maybe I should look into the AmiSSL ticket to get some more insight.
Probably only the bss section, because the data section contains the program code, which should be re-entrant, so can be shared?
.bss (uninitialized data, 0) and .data, the code is in .text.
Quote:
I don't get it how it works/worked. An executable gets loaded by the elf library, and the elf.library set ups the initial task for the executable. The initial task executes the special C library startup code and setup the baserel stuff. If the executable gets started a second time. Nothing is shared from the first run, hence two complete disjoint setup even being the same program.
Yes, but each time it's started the C library startup codes creates a new copy of .data/.bss, sets R2 to it, and frees the copy after it exits.
Quote:
The only setup I can come to mind is a amiga library. Which gets executed by multiple task simultaneously, and each task would have its own parameter/variable memory block.
AmiSSL uses it that way.
But the most use case is loading executables resident, which can be done on AmigaOS with the C:Resident command, or by setting the p(ure) (=re-entrant) and h(old) (=keep in memory) protection bits. For example for shell commands used often that's much faster since it only has to be loaded once from disk (and code and rodata relocation done only once by elf.library) and isn't unloaded after it exits. The next time it's simply started from memory, and it can be executed multiple times by different shells at the same time. Of course that can only work if every task/shell running it has an own copy of the .data/.bss, only .text (code) and .rodata (read-only data) are shared. Even if it's not executed by different tasks at the same time the copy of .bss/.data is required since the program may modify global variables in .bss/.data but only works if they are set to the initial values at program start.
Quote:
So for me it still more or less the same, except the used register, and maybe the baserel has no size limitation. But I'm not sure about that.
Except for the size limit, and requiring the special BREL relocations, it's basically the same as R13 small-data (unless there are some other differences I forgot), but there is only a .data/.bss copying startup code for baserel, none for small-data. The same startup code is used with and without -msmall-data.
I'm a little late to this thread, but thankfully @joerg has explained most things. He and I are probably only two of a handful of developers who used -mbaserel - IIRC, both OWB and Timberwolf use it. IBrowse 2.5 used to use it, but I switched to using -msdata instead...
One of the good things about -mbaserel is that the compiler allowed developers to easily restore r2 for library interface functions, for example, like __saveds did on OS3. There is no such thing for restoring r13, so you have to do the r13 save/restoring manually using asm instead.
AmiSSL is likely to always use -mbaserel because although the data size that OpenSSL uses is not yet 64K, its getting close and will no doubt go over that limit in the future. It is not feasible to patch OpenSSL to use less data.
GCC 4.0.4 (available as native and cross-compiler) was the last version to fully support -mbaserel and generate the correct code, hence why we are stuck with it for AmiSSL. IIRC, the linker and binutils from 4.2.4 did also handle baserel correctly, but the compiler itself created broken baserel code.
Libraries and startup code use the elf library CopyDataSegment() function to copy and relocate the data segment (segment, not section) and FreeDataSegmentCopy() when done with it. These functions were slightly buggy until I fixed them in V53.35.
But the most use case is loading executables resident, which can be done on AmigaOS with the C:Resident command, or by setting the p(ure) (=re-entrant) and h(old) (=keep in memory) protection bits. For example for shell commands used often that's much faster since it only has to be loaded once from disk (and code and rodata relocation done only once by elf.library) and isn't unloaded after it exits. The next time it's simply started from memory, and it can be executed multiple times by different shells at the same time. Of course that can only work if every task/shell running it has an own copy of the .data/.bss, only .text (code) and .rodata (read-only data) are shared. Even if it's not executed by different tasks at the same time the copy of .bss/.data is required since the program may modify global variables in .bss/.data but only works if they are set to the initial values at program start.
Now things start to clear up for me. Now makes all sense.
BTW, If i understand it correctly it is a nice feature of AmiagOS, that i can make executrices resident (aka cache them in memory) and thus speed up the execution, and if it calls multipel times at "once" reduce memory usage. I wasn't aware of that!
@Futaura & Co
I think that binutils (old and new in progress) have all things in place to support baserel. But gcc needs update to in regards to this feature.
Anyway, it seems that gcc 2.x.y still supported baserel out of the box. So it seems that other targets even used to use or could use baserel. Does anyone know why it was drop out of gcc development?
If we switch the viewpoint more to gcc and code generating: For me baserel and small data model is more er less the same concept except different used register. BUT i see that baserel does suffer from the ~65K size limitation. How is that achieved?
@kas1e
So to test the new binutils support for baserel, we need a setup of gcc 4.0.4 and new binutils.
So to test the new binutils support for baserel, we need a setup of gcc 4.0.4 and new binutils.
No problems, already done :) we need test case now, to see if it works with gcc 4.0.4 and binutils from adtools and/or older binutils coming in those times with gcc 4.x
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
