0

I'm working on stm32f469 doing some bare metal code to try to use the libtomcrypt / libtomfastmath libraries. The code I'm trying to debug has been checked by valgrind and is working on many platforms like macos, raspberrypi, ios, android.

To keep things simple, I am doing the following which is calling this function int register_hash(const struct ltc_hash_descriptor *hash) with a const static variable by giving it's adress : register_hash(&sha256_desc). The problem is, once I am inside the function, the hash pointer is NULL and I cannot figure out why.

I was thinking It would be a stack overflow so I pre-filled the stack with the constant value 0xdeadbeef and I checked if all these values were erased or not and the result is the stack is not overflowed.

When debugging, I can verify the value at the address returned by &sha256_desc and the memory is not corrupted there either.

I am not doing dynamic allocations nor buffer filling that could be overflowing and corrupting the memory.

I'm compiling with arm-none-eabi-gcc, version 7-2017-q4-major.

I am mainly looking for some possible sources of issue as I am running out of ideas.

Sourav Ghosh
  • 133,132
  • 16
  • 183
  • 261
Damien
  • 164
  • 11
  • 4
    Even though this description looks quite clear, I guess a [mcve] would still help. Think about people trying to reproduce the exact problem ... –  Jul 04 '18 at 13:03
  • 1
    I can tell you that at some point your code is not doing what you think it is doing. However, since you only told us what you think your code is doing, it's hard to tell where your code does not do what you think it's doing. ;-) – DevSolar Jul 04 '18 at 13:11
  • Are you sure the declaration of your function match with the definition of your function ? – Stargateur Jul 04 '18 at 13:13
  • 1
    Out of curiosity: what *is* the value of `&sha256_desc`? It’s not `0x00000000`, is it? I mean, it *is* a `static const` variable, which may be stored in Flash, which on the STM32F4xx starts at `0x00000000`. Is it the first constant static variable you create? What does the linker’s `.ld` and `.map` files show? – John Burger Jul 04 '18 at 13:21
  • Interesting, but if an all-zero-bits pointer is valid for that platform, shouldn't the null pointer be encoded differently? –  Jul 04 '18 at 13:25
  • @FelixPalmen I am facing this issue in a work context so I am unfortunately not able to provide some example code. I tried to just use this failing function in a minimal code example and this time it worked (this was expected as the library has been working on other platforms) – Damien Jul 04 '18 at 14:24
  • @Stargateur Yes, you can find the declaration [here](https://github.com/libtom/libtomcrypt/blob/develop/src/headers/tomcrypt_hash.h#L492) and the definition [here](https://github.com/libtom/libtomcrypt/blob/develop/src/misc/crypt/crypt_register_hash.c#L21) – Damien Jul 04 '18 at 14:25
  • @JohnBurger No the value is not 0x00000000. This address is the one of the isr_vector. The sha256_desc const static variable is coming from a static library that i compile externally and link to my project. – Damien Jul 04 '18 at 14:26
  • Smells like the external linking is somehow broken; maybe you should dive into the assembler code of the resulting binary (caller and callee) to find the rootcause of this issue. – Ctx Jul 04 '18 at 14:38
  • Thanks for your suggestion @Ctx, I tried to compile everything at the same time and the issue was gone ! – Damien Jul 04 '18 at 16:23

1 Answers1

0

Thanks to @Ctx's comment I solved the issue by compiling all the files in one place instead of compiling a static library later linked to my program.

I don't know what was the problem and because I have new issues blocking me I won't try to investigate further.

Damien
  • 164
  • 11
  • The problem was (almost certainly) that the two different compiles used different compiler options, that conflicted when the linker tried to link everything together. By compiling everything together, you ensure that the same compiler options are used throughout – John Burger Jul 05 '18 at 02:17
  • I agree with this idea @JohnBurger but I literally used the exact same flags at some point to avoid any issue from this, except maybe the level of optimisations. Maybe I could quickly give it a look – Damien Jul 05 '18 at 06:12