environment register / ABI

environment register / ABI

[Martin Uecker]

Hi all,

does anybody know if all architectures support passing
an environment pointer in their function call ABI? 

Are the some where this does not exist?

Is there are table somewhere which lists the
register (or stack slot) used for this for
all architectures?

Somehow I could not find this information easily.
One could assemble this going through all the
ports, but maybe it exists somewhere already.

Best
Martin

Re: environment register / ABI

[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? 

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.

Re: environment register / ABI

[Martin Uecker]

Am Mittwoch, dem 13.10.2021 um 15:21 +0000 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

[Joseph Myers]

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
joseph@codesourcery.com

Re: environment register / ABI

[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).

> > 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

[Martin Uecker]

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