problems using stdarg with floats

[WEREMSOFT]

I have this weird behavior when I try to use a variadic function (like printf) and a float. In an unexpected turn of events, the program only crash when using a float, but it works if I use an int.

this is the code I'm working on:

The following code works

#include <stdarg.h>

float sarasa(const char* format, ...)
{
    va_list args;
    va_start(args, format);
	float returnValue = 2.4 * 123.4;
	return returnValue;
}

int main(void)
{
	float cadorna = sarasa("sarasa", 12);
}

the following code fails

#include <stdarg.h>

float sarasa(const char* format, ...)
{
    va_list args;
    va_start(args, format);
	float returnValue = 2.4 * 123.4;
	return returnValue;
}

int main(void)
{
	float cadorna = sarasa("sarasa", 12.5);
}

What I'm missing? I think the stdarg.h is creating a stack corruption, but I don't have evidence.

[WEREMSOFT]

ok, seems that is a common problem that using float as an argument of variadic function in x64 creates a crash based on how registers and stack is being used. I don't fully understand the problem though, but I'll change the printf function to accept only one argument.

[IanSeyler]

This looks like the float issues I saw earlier. If you disassemble your app look for the instruction at address 0x9D. I'm wondering if it is a SSE instruction.

Easiest way to do this is get ImHex.
Load the .app file into ImHex. Make sure the Disassembler view is on. Set the position to 0xFFFF8000000000000. Set the architecture to Intel x86 and then set it to 64-bit. Click on the Disassemble button.

Scroll down to address 0xFFFF80000000009D

[WEREMSOFT]

I highly recommend use the code provided in the first post in this thread since is more compact. But if you want to use the code on the printf function you should use the one provided on my cube 3d pull request. All you have to do is provide a float in the printf. Doesn’t matter if you put a %f in the format string. The code fails when you send a float using the stdarg.h functionality.

[WEREMSOFT]

Maybe I should rename the function to “debugPrint” or something like that so people will not expect a printf implementation.

[IanSeyler]

debugPrint works for me. At some point we need a full C lib ported anyway. I had newlib working before.

[WEREMSOFT]

Ok, I don't have experience with newlib.

That said, I don't know if that is a good idea, like, if you put a full standard C library on the OS, people will expect it to be fully functional. Like, fopen, fclose, malloc, calloc, pthreads, etc.

I think it will create a lot of stress in the project and it will set a path where you are going to have all this TODO's to provide a development support. Right now somebody says "oh, this is not working", you can fix it in a weekend. If you try to implement support for a standard library you are going to loose this ability or have a lot more stuff on your plate. When I sit to work with BareMetal-OS, I know that I don't have a standard library, and I'm ok with that.

Even if you decide to not implement certain functionality (like filesystem) you have to document what is supported and what not.

But you know better.

[IanSeyler]

You make a good point there. With the simplicity of what the kernel is providing a full C lib wouldn't be that useful.