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). > > 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? 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). 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. There may be more items that can be imagined to be stuffed into a fat function pointer. 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 :) Ciao, Michael.
