Hi,
I contribute to an open source operating system called AROS, which uses an
AmigaOS based ABI/API(s) (including shared library calling conventions)
We have successfully been using patched version of GCC (currently up to
8.3) to build our code but some of it is handled very inefficiently and I
would like advice on how we can better deal with it or possibly get GCC
modified to allow us to use standard code better for our shared libraries.
The problem for us boils down to exposing functions as shared library entry
points. On AmigaOS libraries pass a pointer to a library "base" as the last
parameter - which acts somewhat like a got.
To try and allow for this we have to currently either hack up the code
heavily for all external projects to include the extra parameter or try to
write complex macros to wrap around the function but they often don't work
as well as we would like or have problems with things like forward
declarations.
Ideally we would _love_ to be able to use something like
patchable_function_entry,
however it doesn't really do what we want.
What would work or something that is similar - and would probably be quite
usable in other scenarios out with the AROS operating system or amiga like
operating systems, is if we could use an attribute such as -:
extern void *
somegenericcfunc (char *normalparam, size_t anotherparam)
__attribute__((hiddenparam (-1, struct Library *ourwantedbase)));
So that we can just provide it to the compiler in a header when the unit is
compiled or other units that use it - and the compiler would automatically
know to "expand" the prototype to include this parameter
In the example above - the "-1" would be used to represent inserting the
parameter at the default (very last) location, otherwise it would be a
positive value to specify the position it should be inserted.
One of our developers had mentioned using the %ebx register by preventing
gcc using it in code but this seems very inefficient and wasteful (and not
possible on all architectures) if something like the above could be
implemented instead - which would allow the compiler to best decide then
what to actual do with the parameter and which registers to use.
I would really appreciate any advice or help anyone can give on this
subject … or if implementing a parameter as described would be
desirable/acceptable and feasible?
Thanks for your time ..
Nick Andrews
(aka kalamatee)
