I'm trying to make a simplified printf that does not rely on stdarg.h and its accompanying baggage, so I need the source to the va_args functions. Including stdarg.h tends to pull in all sorts of extraneous library functions.
The source for libgcc was my first guess, but good gravy, it could take a year to unravel that stuff.
Does anyone have a clean va_args source to share, i.e., va_start, va_end, va_list in source that would be compiler independent?
Scott
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4581 (20091107) __________
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
8051. Or passed in fixed static memory locations assigned and reused. Also, parameters can be _spilled_ out of registers by the compiler if their address is taken in the routine.
As you imply, the OP needs to disclose the compiler toolset and target before getting closer to a meaningful answer.
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) __________
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:
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).
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) __________
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.
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.
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.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.