This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

gcc does not generate correct code while building PIC

Hey guys,

I have been exploring building PIC using the gcc toolchain and I think there is a bug.

I first build a shared library using 

and then link to my code using the follwing

Full code is at https://github.com/rgujju/STM32-projects/tree/master/got_plt , generate the required code using 'make got_plt'. I have also attached the disassembly of the code at the end for convenience.

What I expect is the function call to <library_function> to go through the GOT and PLT and eventually go into the .dynamic section. I understand that i will have to build a dynamic linker for the actual call to <library_function> work but i just want to check if it runs till this point correctly first. But the code gives a fault at 0x800010c. The branch to the instruction at 0x800010c is from 0x8000126. The value of ip at 0x8000126 is 0x200000a0, hence the PC gets loaded with 0x800010c. The CFSR value after the fault is 0x00020001 which is IACCVIOL and INVSTATE. INVSTATE occurs when the last bit is not set to 1 for a thumb2 instruction. So I changed the 0x800010c to 0x800010d and it seems to work fine.

So my question is, is this actually a bug in gcc or am i doing something wrong?

Thanks a lot for your help.

EDIT: I am using arm gcc 9-2019-q4-major

EDIT: Added GBD output

From https://interrupt.memfault.com/blog/cortex-m-fault-debug

INVSTATE - Indicates the processor has tried to execute an instruction with an invalid Execution Program Status Register (EPSR) value. Among other things the ESPR tracks whether or not the processor is in thumb mode state. Instructions which use “interworking addresses”2 (bx & blx or ldr & ldm when loading a pc-relative value) must set bit[0] of the instruction to 1 as this is used to update ESPR.T. If this rule is violated, a INVSTATE exception will be generated. When writing C code, the compiler will take care of this automatically, but this is a common bug which can arise when hand-writing assembly.

0