Base relative variable addressing
m68k the SAS/C compiler had the possibility to use the A4 register as a
base address for accessing global variables. This way so called pure
programs can be generated, these are programs that can be loaded once
into memory and run several times. Every time when then the program is
started then room is allocated for the variables and the A4 variable is
set to the allocated memory.
Such a feature is also needed on the i386
options have been examined in the past to see how this feature could
best be provided on i386. Currently it has been settled on using the
%ebx register for this purpose. This is analog to the SYSV i386 ABI
where %ebx can be reserved for use as global offset table (GOT) for
position independent code.
The register has been reserved for this
purpose by adding the -ffixed-ebx option to the gcc specs file. This
means that gcc will not generate code that accesses the %ebx register
so it is reserved for other system use.
The consequence is that you
can't use the "b" constraint anymore on inline asm in gcc for input or
output arguments. This constraint would allow putting arguments in the
%ebx register but gcc gives an error because it is supposed to not use
this register; inline asm statements of external code may thus need to
be changed to work on AROS.
macros (AROS_GET_RELBASE and AROS_SET_RELBASE) are defined to access
this variable. These hase to be defined by cpu.h for a certain cpu
otherwise you will get a compile error.
At the moment no patch for gcc is
available for using the --baserel option on i386 for producing
pure code for AROS. Feel free to implement it.
At the moment on i386 this register is also used for passing the libbase pointer.
Other optionsOtherOther things have been considered and some even tested for a good place to store the relbase. Here are some summaries:
system global variable. Analog currently to the SysBase variable there
would be a __relbase global variable where the value is provided by the
ELF loader. This approach works but this path was left when %ebx was
discovered and it's analogy to the SYSV usage of this register.
or %gs:n: Another possiblity would be to use the i386 segment registers
for accessing the relbase. Also here %ebx is currently considered a
better solution. The impact of using the segment registers on a hosted
version of AROS is not fully clear yet.
- ThisTask->relbase. Could be an alternative but %ebx seems better.