va_args (va_start, va_end, va_list ) souce?

Op Sat, 07 Nov 2009 18:52:20 +0100 schreef Not Really Me :

These are CPU dependent. Some arguments might be in registers, some might be on the stack.

Worse, this can also depend upon #pragma, extended keywords not explicitly part of the c standard, and compile options, as well. For example, parameters may be placed in an XRAM parameter stack on the

As you imply, the OP needs to disclose the compiler toolset and target before getting closer to a meaningful answer.

Jon

No can do. For starters, the va_args functionality consists of macros, not functions. I.e. the bulk of it is _in_ . Trying to implement a variadic function without it would be quite exactly like trying to make omelettes without a pan.

If so, that'll be because it has to.

Variable argument lists are pretty much by definition totally system-specific. They depend on the compiler, the switches it was invoked with, the operating system ABI, and all sorts of other things.

grumble, grumble. I suppose you are both right. It really does have to be processor/compiler specific. Sometimes it is only clear when someone else points it out.

Thanks, Scott

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4588 (20091109) __________

The message was checked by ESET NOD32 Antivirus.

They're macros, not functions. The fact that the second argument to va_arg() is a type should be a clue (you can't pass a type as a function argument).

Nope; try the source for gcc itself.

gcc's stdarg.h (it's part of gcc, not libc) defines them as:

#define va_start(v,l) __builtin_va_start(v,l) #define va_end(v) __builtin_va_end(v) #define va_arg(v,l) __builtin_va_arg(v,l)

the __builtin_* "functions" are rather like what Lisp calls "special forms": neither functions nor macros, but constructs which the compiler recognises and handles specially.

If you want to write equivalents, you need to know the details of the platform's calling convention, i.e. which arguments will be in which registers, which will be on the stack (and where).

If you're lucky, the compiler will just push all of the unspecified arguments onto the stack in right-to-left order, so va_arg() is just essentially "(*((type *)(ap))++)"; most x86 platforms behave like this. If you're not so lucky, you will have to enumerate all of the possible combinations of argument types until the registers have been exhausted (after which, the rest will be on the stack).

Also, some platforms use a different calling convention for variadic functions (e.g. Windows uses "cdecl" rather than "stdcall"), in which case the convention for variadic functions is often simpler (e.g. pushing all unspecified arguments onto the stack rather than using registers).

This code assumes arguments on the stack. There are STDARG.H macro definitions in there, but be sure to check the assumptions I made with those.

Hi Chris,

Hey, that's the code I used in a lot of my own projects (after I dumped newlib for small systems).

Thanks for making it available!

Thanks. It could be real useful in the future. My current project is using Wind River Compiler for PPC and it uses registers for the first seven arguments.

As others so helpfully pointed out, that is the reason the _va macros are compiler specific.

Scott

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4595 (20091111) __________

The message was checked by ESET NOD32 Antivirus.

s using

Functions with variable number of arguments receive all their variable arguments through stack. The macros dealing with accessing the arguments on the stack are compiler (and possibly OS, because of calling conventions) specific, but their purpose is simple enough - walk through a stack frame.

That's compiler dependent and frequently not the case. Even on x86.

Steve

Usually, the last named parameter at a fixed location marks the start of the rest. Not _every_ parameter related to the variable argument list is _always_ on the stack. At least, not right away. And, I suspect, even the variable parameter list itself can be placed on specialized software stacks that may be compiler dependent (I think SDCC supports something like that, but haven't done enough reading to know.) If the macros for getting started on the list do take the address of that last named parameter, it will at least get spilled to some place where an address can be had. But where even that is, isn't guaranteed by the language.

The basic principle is indeed simple enough. It's just all that hairy practice of competing in a compiler world that can get in the way and make something otherwise quite easy to follow, less so in the end.

Best to know what your compiler does and not assume that some one bit of c code will be able to port across well. The author said, "I'm trying to make a simplified printf that does not rely on stdarg.h and its accompanying baggage." I think the OP should at least be aware that it would be wise to annotate whatever he does decide to do in that code so that others, perhaps ignorantly, attempting to port it elsewhere may have a clue what needs to be examined and possibly modified based upon the circumstances at hand.

Jon

P.S. setjmp() and longjmp() are also pretty easy to follow, in concept. Then objects in c++ impinge and the whole idea goes down a nasty rat hole of complexity, if it works at all. Back to the main point, stdarg.h is what it is for a reason.

I am yet to see something like that. Can you post an example which is easiest for you to reproduce?

ARM compilers that follow the ARM procedure call standard put the first 4 words of the arguments in registers a1-a4, and the remaining words on the stack.

It makes sense, because the calling function may not know that the called function takes a variable number of arguments (if there was no prototype declaration).

Inside the variadic function, the arguments that were passed in registers can be pushed on the stack to simplify the va_args macros.

By the standard it's the last named which is passed to the macros. So, yes, it must lead to the others somehow. I can imagine implementation in which additional argument is passed which is a pointer to the varargs frame.

Related to or included into? I do mean the latter only.

Wherever the chunk with varargs goes, it's still a frame that gets scanned depending on type size/alignment. My use of "stack" is general for simplicity.

Yes. What I said is that the varargs themselves are grouped together on the "stack" (taking my previous remark about the general use of this word) and never passed through registers.

I'd be very interested to see implementation that does otherwise.

IMHO the way of handling varargs is very well thought, given the great _freedom_ that the 'C' language gives for the underlying hardware and the even greater implications therefore. You can have different frame layouts with the same compiler, just a matter of different options, so there can't be much more elegant solution.

The OP can make their own printf() easy enough, but not using is call for disaster if he's going to use it on more than one combination of CPU/OS/compiler. That's why was standardised in the first place! GNU C even has the macros simply expand to builtins - try to replace that.

Indeed.

Good point.

Checked with arm-gcc. Varargs partly get into registers r0..r3 and the variadic function first does "stmfd sp!, {r0, r1, r2, r3}" so the frame is contiguous.

Thanks for the example! I stand corrected.