Parameter order for Struct

[kid joe]

Hi,

I'm using assembler and C code together. Now suppose I have the following:

struct foo {
int x;
int y;
...
}

void bar(struct foo)
{
...
};

My question is: Is the order of the struct vars on the stack (i.e. y, x)
is defined within C.

In my assembler code, I need to push the values onto the stack and then
call bar(). My code is working for me, but I want to know whether it is a
defined behaviour or it is specific to gcc.

Thanks!

 

[Richard Tobin]

I'm using assembler and C code together. Now suppose I have the following:

struct foo {
int x;
int y;
...
}

void bar(struct foo)
{
...
};

My question is: Is the order of the struct vars on the stack (i.e. y, x)
is defined within C.

In my assembler code, I need to push the values onto the stack and then
call bar(). My code is working for me, but I want to know whether it is a
defined behaviour or it is specific to gcc.

The order of the members is defined - the addresses must increase - but
there may be padding between them.

You can use the offsetof() macro to find the offset of a member within
a structure, but how you communicate that to your assembler code is
more of a problem. You could run a program to output the offsets.

-- Richard

 

[Antoninus Twink]

My question is: Is the order of the struct vars on the stack (i.e. y, x)
is defined within C.

In my assembler code, I need to push the values onto the stack and then
call bar(). My code is working for me, but I want to know whether it is a
defined behaviour or it is specific to gcc.

The standard C calling convention (known as cdecl) is to push parameters
in right-to-left order - this facilitates variadic functions like
printf(). It's possible that a compiler could adopt another
convention (e.g. passing some parameters in registers), but this is
unlikely unless you give it some special __attribute__ directive or
similar.

For structs, different compilers will decide to do different things.
It's a pretty safe bet that a very simple struct (e.g. your two ints)
will just be pushed directly onto the stack. However, for a more
complicated struct, you may find that the compiler makes a copy of it in
some temporary memory, and then pushes a pointer to that copy instead.
Different compilers may set the "complication threshold" for choosing
one method or the other differently.

 

[Walter Roberson]

On 2 Jun 2008 at 22:43, kid joe wrote:

The standard C calling convention (known as cdecl) is to push parameters
in right-to-left order - this facilitates variadic functions like
printf(). It's possible that a compiler could adopt another
convention (e.g. passing some parameters in registers), but this is
unlikely unless you give it some special __attribute__ directive or
similar.

Of course, on some systems, other parameter passing mechanisms
are the rule of the day, with -no- special compilation options.
Like machines which pass parameters through "register window"
mechanisms (sparc); or ABIs that pass up to the first four (left to right)
parameters in registers, stopping at the first non-integral parameter
(old MIPS abi).

stack: does not have to exist at all

parameter order: some systems use different parameter passing
conventions dependant upon whether the routine is a leaf node
(calls no other routines) or not, so it isn't even certain
to be the same for all calls. And on some systems, the number of
parameters passed through various mechanisms can depend upon the
Intra-Procedural Analysis (IPA) results, e.g., possibly
passing more parameters in registers if the analysis of -all-
of the places the routine is called shows that there are some
registers available that are normally reserved for specific
purposes but whose function is unneeded by the routines

padding: yup, you have to take padding into account, and the
C compiler will not necessarily agree with a naive assembler routine

structure addresses: like one of the posters said, the various
members of the structure must be in increasing address order. That
isn't an option: it is written into the language. But member orders
in a structure need not be the same as parameter order for independant
parameters to a routine.

 

[Martin Ambuhl]

My question is: Is the order of the struct vars on the stack (i.e. y, x)
is defined within C.

While many implementations of C use a stack, the standard that defines C
in no way requires (or even suggests) a stack. That being so, there is
nothing in the C language specifying _anything_ about how a stack, which
may or may not exists, will be used.

Since even the existence of a stack and certainly its use, if it exists,
are implementation details, you need to ask people concerned with your
implementation. In your case,

My code is working for me, but I want to know whether it is a
defined behaviour or it is specific to gcc.

suggests that you post to a gnu newsgroup. There is massive
documentation available for gcc, and all its source code as well. If
this is an important issue for you and if the gnu newsgroup cannot
answer your question, the material is easily available to do your own
research.

 

[Richard Tobin]

My question is: Is the order of the struct vars on the stack (i.e. y, x)
is defined within C.

[/QUOTE]

While many implementations of C use a stack, the standard that defines C
in no way requires (or even suggests) a stack. That being so, there is
nothing in the C language specifying _anything_ about how a stack, which
may or may not exists, will be used.

However, the order of the *addresses* is specified by the standard,
which may be the important thing.

suggests that you post to a gnu newsgroup.

He knows what it does in gcc. He wants to know what it does in
everything else. comp.lang.c is the right place for that.

-- Richard

 

[Robert Spykerman]

If your stack grows toward higher addresses (which is likely the case),
then it is a requirement to "push" y first.

Slightly off topic, and I speak with limited platform experience (x86,
ppc), but the kind of stack that's usually involved in this case (ie
the one in ESP or $1) tends to grow _downwards_ from high memory.

It's usually the heap that grows upwards, or if you don't have one,
whatever equivalent you have.

What and how it gets passed is of course implementation specific, and
it's a good idea to check the ABI (and compiler specs - some compilers
resort to trickery to minimise the overhead of creation and
destruction of stack frames) of said implementation.

Also note the ABI's can change even within the same processor within
the 'same' OS for different machine word lengths, ie ABI's for 32 bit
code are not necessarily the same for 64 bit code.

Robert Spykerman

 

[Flash Gordon]

Robert Spykerman wrote, On 03/06/08 12:54:

Slightly off topic, and I speak with limited platform experience (x86,
ppc), but the kind of stack that's usually involved in this case (ie
the one in ESP or $1) tends to grow _downwards_ from high memory.

It's usually the heap that grows upwards, or if you don't have one,
whatever equivalent you have.

Until recently I had easy access to a machine where the stack grew up
(well, certainly in the opposite direction to all my other machines) but
I have no idea how the heap was managed on that machine (assuming it had
something called a heap). It was an RS6000 running AIX 5.3. I still have
access to the machine, but it is switched off until I need it again for
work.

What and how it gets passed is of course implementation specific, and
it's a good idea to check the ABI (and compiler specs - some compilers
resort to trickery to minimise the overhead of creation and
destruction of stack frames) of said implementation.

Also note the ABI's can change even within the same processor within
the 'same' OS for different machine word lengths, ie ABI's for 32 bit
code are not necessarily the same for 64 bit code.

Also for discussion of how a particular implementation works the OP
should go to a group dedicated to that implementation.