Re: environment register / ABI
Am Donnerstag, dem 14.10.2021 um 13:17 + 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
Re: environment register / ABI
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.
Re: environment register / ABI
On Wed, 13 Oct 2021, Martin Uecker wrote: > 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. This doesn't answer your actual question, but: Following discussions of atomics at the last WG14 meeting, I raised the question on the WG14 reflector (and C++ liaison list) of whether it would be useful to have a public list of C-relevant ABIs and their maintainer contacts and ABI-relevant new features in C language versions. I was thinking of such a list as being to help people do due diligence after making ABI-relevant C standard changes (contacting the main ABI maintainers to get them to add ABI specification for the new features) and to help ABI maintainers track new features for which they need to update their ABIs. But such a list could equally be relevant for such research as you mention above in advance of proposing a new feature. There weren't any replies to my message from anyone actually saying they'd find such a list useful. If you think such a list would be useful (for the community of people dealing with maintaining ABIs or ABI implementations or specifying new language features needing corresponding ABIs), then I'd encourage replying to my reflector message of 2 September to say so. Message of 2 September below, for reference of readers not on the WG14 reflector or C++ liaison list: == To expand on something I mentioned in the atomics discussion in today's WG14 meeting: When new ABI-relevant features have been added to C, the community of people involved in C implementations hasn't always done well at updating relevant ABIs to achieve consistency between implementations for those new features (where those implementations aim to allow mixing code built with different implementations for the same architecture/OS - this isn't relevant for all C implementations). Atomics are just one example where the ABI issues are more complicated than usual, and where actual incompatibilities have arisen between implementations as well as between C and C++. Should there be some maintained public list of C-relevant ABI documents (mainly, not entirely, psABI documents for various architectures), and of where they are maintained (if they are) / who the maintainer contacts are? What about lists of ABI-relevant new features in different C versions that ABIs may need to be updated for (and, for that matter, common extensions it may be helpful to consider in ABIs), or some mailing list or other location to help psABI maintainers (and other relevant ABI maintainers - for example, new features often need to be handled by debug info formats such as DWARF as well) track new features they need to pay attention to? Or guidance on issues to consider when writing a psABI document? Do such lists already exist somewhere? As an example of the sort of thing I might hope to find in such a list of ABI documents / contacts: * x86-64: PDFs https://gitlab.com/x86-psABIs/x86-64-ABI/-/wikis/x86-64-psABI repository https://gitlab.com/x86-psABIs/x86-64-ABI mailing list https://groups.google.com/g/x86-64-abi * i386: PDFs https://gitlab.com/x86-psABIs/i386-ABI/-/wikis/Intel386-psABI repository https://gitlab.com/x86-psABIs/i386-ABI/-/tree/hjl/x86/master mailing list https://groups.google.com/g/ia32-abi * Arm and AArch64: PDFs https://github.com/ARM-software/abi-aa/releases repository https://github.com/ARM-software/abi-aa * RISC-V: PDFs https://github.com/riscv/riscv-elf-psabi-doc/releases repository https://github.com/riscv/riscv-elf-psabi-doc (but hopefully covering more architectures than that). -- Joseph S. Myers jos...@codesourcery.com
Re: environment register / ABI
Am Mittwoch, dem 13.10.2021 um 15:21 + schrieb Michael Matz: > Hello, > > On Wed, 13 Oct 2021, Martin Uecker wrote: > > > does anybody know if all architectures support passing > > an environment pointer in their function call ABI? > ... > > Or you could mean what normally would be called 'static chain', i.e. > a pointer to the stack frame of outer functions for languages > supporting nested functions. I could imagine this also be called > environment. Yes, sorry for not being clear. It is sometimes called environment pointer. > 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. > 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. Martin
Re: environment register / ABI
Hello, On Wed, 13 Oct 2021, Martin Uecker wrote: > does anybody know if all architectures support passing > an environment pointer in their function call ABI? Define "environment pointer". I can imagine two things you could mean: the custom to pass envp as third argument to main() in hosted C programs: int main (int argc, char *argv[], char *envp[]); but then this is specific to main and more a question of process initialization than function call ABI. If you mean this the answer will most often be: if envp is passed to main (a question of the operating system or runtime environment, e.g. if there's something like an environment in the getenv() sense to start with), then it is passed like any other third argument of pointer type on the psABI in question, and that definition would be independend of the psABI. Or you could mean what normally would be called 'static chain', i.e. a pointer to the stack frame of outer functions for languages supporting nested functions. I could imagine this also be called environment. If you mean that, then it's indeed psABI specific, and possibly not all 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. Or do you mean something else entirely? It might also help to know the purpose of your question :) Ciao, Michael.