Using multiple precision in bare-metal c

3
votes

So I have a raspberry pi zero and I followed along this really cool tutorial to have a starting point at programming it in bare metal c. Everything's been working good.

Now for what I want to do I need (unsigned) integers with a size of 256 or 512 bit, so I went looking for libraries. I found BigDigits and got it to work easily on my machine.

When I tried to compile it with the rest of my actual bare metal code though (without even including it or using it anywhere in my code) it compiled and linked without warnings or errors but my code doesn't work anymore, i.e. my raspberry pi doesn't do what it did before.

I'm still pretty new to bare-metal programming. I know that there might be system functions used by the library that are not implemented and might therefore not work correctly. But I'm not even calling any BigDigits function, nor am I including any of their headers.

So why does it compile and link but not work? And how could I make it work or are there any other options that would be easier to use in a bare-metal c environment for arbitrary precision? I actually always know at compile time what precision I need so I'd be happy to just have uint256_t types or something like that, but I couldn't find anything like that.

Thanks in advance!

1
craspberry-pibare-metalarbitrary-precision
When programming in bare metal you must pay attention to functions used, or introduced, by the code you use, with particular reference to memory allocations, I/O functions and C system calls. These will trigger constructs of the compiler base library that may need to be tweecked and confingured. Some weak functions used as placeholder may be replaced by new code entries that are not proper for the bare environment. A a suggestion cut the bignum library to basic part, check allocations (malloc() and free()), and error and I/O functions usage (look to perror()). – Frankie_C
Do you mean something else than what is in the body of the functions? Because I don't call any functions yet, that's why I don't get how it's not working. To my knowledge no code of the library should be run right now. – Rubydragon
I mean that the code you introduced could use some apparently normal functions from the compiler standard library that can call internal code not configured yet. This can trigger exceptions that require appropriate handling, or simply execute code not properly tailored for your bare metal running environment. Check all library functions called inside the code you added. – Frankie_C
As I said, I am aware that the code I introduced could fail when running, but as far as I'm aware I am not calling that code anywhere so it shouldn't run at any point and therefore not be able to cause any interrupts or exceptions. As I said, the only thing I changed was linking the library to my code, I don't include its headers anywhere and I'm not calling its functions anywhere. – Rubydragon
The point is that even code not executed could include symbols conflicting with other defined as weak. In those cases the linker silently replace the weak one with the new. But this is only one of the simpler cases, there could be problems with memory layout or system functions (open, read, write, close, etc.). The code you choose was write for major systems (a complete OS as linux or win), and you couldn't port all of it to a bare metal system as is. You should have reduced the port to the very core of code. Try to port small portions at time, then debug. Difficult to help more... – Frankie_C

1 Answers