Products > Programming

Weird bug in GCC ARM 32F4

(1/2) > >>

peter-h:
The code crashes in the sprintf, into one of the illegal instruction traps. However I found that shortly before it, data which is supposed to be initialised on the stack, isn't. AIUI, if you do say int x=2; inside a function, the compiler generates some code which sets up that data, and it puts it on the stack (unless it is declared "static" in which case it goes into, IIRC, BSS).

Here the bytes remain 0xFF. Does this make any sense to anybody?

The code runs fine when loaded with the STLINK debugger, and has done so for ages. It crashes when loaded from a serial FLASH device, into the CPU FLASH. Then the system reboots (as is necessary) and promptly crashes. Could this data be stored at the very end of the file, and I am failing to load the entire image?

Where in the binary would the string MonTue... be stored - for stuff destined for the stack? I guess it is missing. The 0xFF bytes are indicative of an erased FLASH device. SP and PC look good; the stack is at the top of the 128k RAM.

langwadt:
look at the disassembly

ataradov:
How exactly do you obtain the file that you put into the flash?

This constant string will typically go into .rodata section. Where it is located depends on your linker script. With more or less standard linker scripts, all those strings will be located at the end of the binary, after all the code (text) sections.

Indeed, look at the disassembly and see what is actually going on.

Also, it is not a bug in GCC. It is a bug somewhere in your system. Compiler bugs are much more rare than you think, and chances of you running into one are negligible.

peter-h:
Sorry; didn't mean to say it is a bug in GCC :)

It is a system built with GCC ARM 32F4 :)

The file comes from a FAT file system, originally, implemented on the target via USB. But that aspect of the project has been working for 1+ year, until a few weeks ago. Recently it has grown in size (by replacing PolarSSL with MbedTLS) from 170k to 300k and this issue has appeared. My code should support a file up to 510k (size of the entire binary) so that's not the simple answer, but I can see I may be dropping something off the end..

Disassembly:



I can see the two arrays are initialised to zero with explicit instructions (r5=0 etc). But I can't see how the MonTue... bit gets initialised.

In the linkfile, it does indeed look like rodata is loaded after all the code


--- Code: --- .main.o :
  {
    . = ALIGN(4);
    KEEP(*(.main.o))
    *main.o (.text .text* .rodata .rodata*)
    . = ALIGN(4);
  } >FLASH_APP
 
/* This collects all other stuff, which gets loaded into FLASH after main.o above */
 
  .text :
  {
    . = ALIGN(4);
    *(.text)           /* .text sections (code) */
    *(.text*)          /* .text* sections (code) */
    *(.rodata)         /* .rodata sections (constants, strings, etc.) */
    *(.rodata*)        /* .rodata* sections (constants, strings, etc.) */
    *(.glue_7)         /* glue arm to thumb code */
    *(.glue_7t)        /* glue thumb to arm code */
*(.eh_frame)

    KEEP (*(.init))
    KEEP (*(.fini))

    . = ALIGN(4);
    _etext = .;        /* define a global symbol at end of code */
} >FLASH_APP
--- End code ---

Thank you for any pointers, so to speak.

ataradov:
ldmia and stmia instructions starting from 0x803abc6 is what loads that constant string to the stack.

So you can look at the address stored in r6 before the first instructions is executed. As you can see that address is located in a constant pool at the end of the function and is loaded by the ldr instruction (from address 0x803ac60). Your binary should contain that string at that address.

Navigation

[0] Message Index

[#] Next page