Am Donnerstag, dem 14.10.2021 um 13:17 +0000 schrieb Michael Matz: > Hello, > > On Wed, 13 Oct 2021, Martin Uecker wrote: > > > > [... static chain ...] > > > If you mean that, then it's indeed psABI specific, and possibly > > > not > > > al ABIs specify it (in which case GCC will probably have set a > > > de- > > > facto standard at least for unixy systems). The x86-64 psABI for > > > instance does specify a register for this, which is separate > > > from > > > the normal argument passing registers. Other psABIs could say > > > that > > > it's passed like a hidden argument prepended to the formal list > > > of > > > args. > > > > > > > Yes, most architecture seem to define a register. I am wondering > > if there is a table or summary somewhere. > > Not that I know of, and I doubt it exists. The most comprehensive is > probably the result of (from within gcc sources): > > % grep 'define.*STATIC_CHAIN_REG' config/*/*.[ch] > > (that get's you all archs of GCC that support a static chain in > registers, > and it's often very obvious from above result which one it is), plus > the > result of > > % grep TARGET_STATIC_CHAIN config/*/*.[ch] > > (that get's you the few targets that don't necessarily use a reg for > the > static chain, but e.g. a stack slot or a different register depending > on > circumstances. These are only i386, moxie and xtensa currently, but > you > need to inspect the target hook function to determine when which > place is > used, i.e. not as obvious as above). >
Thank you! From this it seems there are 49 architectures that use a register and three that may use memory or so something more complicated and none which do not support it at all (assuming the vms and vxworks directories include generic OS code and do not count) > > > Or do you mean something else entirely? It might also help to > > > know > > > the purpose of your question :) > > > > There is currently no standard way to set or query > > the static chain from C although this is used by > > many other languages. Also function pointers in C > > usually can not store the static chain. I am going > > to propose to WG14 to add some kind of wide function > > pointer to address this. I am doing back ground > > research to understand whether this exists everywhere. > > I see. Is that sensible without C itself having the possibility to > write nested functions? Well GNU C already has the possibility. Using wide pointers you could use them without requiring an executable stack You can already use them without this by extracting the code pointer and static chain from the trampoline and use __builtin_call_with static_chain to call them instead of going through the trampoline. This works perfectly, except you need to decode the trampoline in a non-portable way. ISO C may get lambda expressions, which then also require similar functionality (C++ has std::function for this). But one of the main motivations that is independent from all this is language interoperability. > There are other, more obvious (for C!) reasons to have > wide function pointers: shared libs often are implemented such that > the static data of a library is reachable by a pointer (often called > GOT pointer, or PIC register or similar terms), so calling an > indirect function needs to setup that GOT pointer plus contain the > function address itself. This is often implemented either by setup > code in the function prologue or by using function descriptors, or > by an extra entry point containing that setup. Fat function pointers > (which effectively are then function descriptors) could contain that > as well. (it will be very target dependend how that would be filled, > but that is the case with static chains as well). Yes, you could call such functions directly using a wide pointer. But the details would be left to the implementation. > There's another case for fat function pointers: C++ virtual methods: > unbound pointers to them will just be type-id plus vtable index (in > the usual implementations of C++), bound pointers will be a function > address plus this pointer. Yes. Borland C++ had a wide function pointer type for this purpose. > There may be more items that can be imagined to be stuffed into a > fatf unction pointer. > Go, Ada, Pascal, ... In fact, using a wide pointer you can call every callable entity because the data part can point to the entity and the code part points to whatever stub code may be needed to call it. > So, I'm wondering what you are pondering about, to which extend you > want to go with fat function pointers, what the usecases will be, > i.e. which problem you want to solve :) > Mostly I have two goals: - I want to have C APIs for callbacks that avoid having an extra void* pointer fo data but nicely encapsulate it into a wide function. - I want this to be interoperable between different languages. If there were a standard C type for wide pointers, all other languages could use it to talk to each other. Martin
