Hi Phil, Yes, you hit the nail on the head: "in a normal implementation of a vararg style function". Unfortunately, printf isn't a normal implementation. It does not reference its parameters the way any normal varargs function would. It takes the data at sp+2 for the pointer to the format string and SP+4 as the address of the argument list. Unfortunately on MSP430X, at SP+2 is the upper word of the return address. Which doesn't make a good job as format string pointer.
If the called function does not know whether it has been called using CALL or CALLA, it cannot know whether there are 2 or 4 bytes return address on the stack. On the other side any function will either return with RET (fetching 16 bit return address and returnign into the lower 64k, no matter whether the calling function was in FARTEXT) or with RETA, fetching a 32 bit return address, even if only 16 bits return address have been placed on stack. If program and library have been compiled to only use one form of calls (CALLA/RETA being the less efficient way, but if you need the additional code segment...), most varargs functions will work without noticing the difference. But printf, since it makes assumptions about the stack topography, needs to perform a different algorithm for both cases. (and IIRC it wasn't written in C at all, but in ASM to allow the parameter forwarding to vprintf without making a function call). My guess was that this necessary adjustment hadn't been done. Just recompiling the lib isn't enough in this very special case. JMGross ----- Ursprüngliche Nachricht ----- Von: Phil Sutherland An: [email protected] Gesendet am: 25 Jan 2010 16:40:31 Betreff: Re: [Mspgcc-users] mspx54xx msp430X mspgcc libc printf not working Alas, I'm not sure this explanation holds water. In a normal implementation of a vararg style function in C the address of the last fixed argument to the function is used as the starting point, and subsequent arguments are located on the stack as offsets from the address of this fixed argument. At a glance, this mechanism appears to be being used in the 430X C library. As luck would have it I've hit some anomalous *printf behavior myself in the last few hours, so I'll dig a bit deeper tomorrow and see what I can come up with - hopefully it'll be the same issue. Cheers phil
