gcc-4.7 -lto -Os funktioniert nicht

[Heiko J. (heiko_j)]

Hallo,

ich bin gerade dabei ein bisschen mit lto herumzuprobieren und bin dabei 
über ein Problemchen gestolpert. Mein Programm läuft nicht mehr. Es 
hüpft direkt in den HardFaultHandler. Ich hab mit dem Debugger im 
ResetHandler einen Breakpoint auf __asm__("ldr   sp, =__stack") gesetzt, 
der nie erreicht wird. Es scheint als würde die CPU den ResetHandler 
überhaupt nicht angucken. :-( Die nvic table und den ResetHandler hab 
ich mit _attribute_ ((used)) gespickt, wie in den diversen Dokus zu 
lto beschrieben. Der Eintrag für den ResetHandler in der NVIC table 
sieht eigentlich auch gut aus. Der Code liegt da wo er hin sollte. 
Irgendwas mach ich wohl falsch,  hab aber absolut keine Ahnung was, 
sobald ich aber -flto beim comile und link weg lasse läuft wieder alles. 
Keine Warnings beim compilieren und linken. Kein Anhaltspunkt.

Hat von euch jemand ne Idee an was es liegen könnte ?

Gruß Heiko


Compileroptionen:
arm-none-eabi-gcc -mthumb -mcpu=cortex-m3 -Os -fno-builtin 
-ffunction-sections -fdata-sections -flto -c -DUSE_STDPERIPH_DRIVER 
-Iinclude -ILibraries/CMSIS/CM3/CoreSupport 
-ILibraries/STM32F10x_StdPeriph_Driver/inc -mthumb -mcpu=cortex-m3 -Os 
-fno-builtin -ffunction-sections -fdata-sections -flto -MMD -MP -MF

Linkeroptionen (Linken über gcc-frontend):
arm-none-eabi-gcc -Os -Tsrc/stm32f107vct6_flash.ld -nostartfiles 
-Wl,--gc-sections -v -mcpu=cortex-m3 -mthumb -specs=nano.specs 
-specs=rdimon.specs -lc -lnosys -lc -u _printf_float -flto


Toolchain: gcc-arm-none-eabi-4_7-2013q2 (Launchpad)
CPU: stm32F107vct6

Disassembly of section .text:

08000000 <nvic_boot_vector>:
 8000000:       00 00 01 20 6d 03 00 08 03 02 00 08 01 02 00 08

...

0800036c <stm32f10xCL_Reset_Handler>:
 800036c:       b500            push    {lr}
 800036e:       b08b            sub     sp, #44 ; 0x2c
 8000370:       f8df d54c       ldr.w   sp, [pc, #1356] ; 80008c0 <_close+0x6>
...

 
__attribute__ ((externally_visible,used)) void stm32f10xCL_Reset_Handler(void) {

    // Adjust sp       
    __asm__("ldr   sp, =__stack");

    unsigned int * ptrDst;
    unsigned int * ptrSrc;

#ifdef DEBUG_IN_RAM        
    /* run in ram shit that makes me insane ....*/
    unsigned int * vtor = (unsigned int *) VTOR;
    *vtor = (unsigned int) &__start_bootnvic_vector;
#else
    /* Copy data section from flash to RAM */
    ptrSrc = &__start_cpy_src;
    ptrDst = &__start_cpy_dst;
    while (ptrDst < &__end_cpy_dst) {
        *ptrDst++ = *ptrSrc++;
    }
#endif

    /* Clear the bss section */
    ptrDst = &__bss_start__;
    while (ptrDst < &__bss_end__) {
        *ptrDst++ = 0;
    }

    // Go and launch main
    main();

    // We'll hopefully never ever get here
    while (1) {
    }
}

[(prx) A. K. (prx)]

Es ist bei diversen ARMs nicht trivial, direkt ab Reset zu debuggen. Der 
Reset löst da nämlich die Verbindung zum Debugger, und bis der die CPU 
wieder eingefangen hat, ist dein LDR schon durch.

Wer sicher gehen will, der legt direkt hinter an den Anfang vom 
Reset-Code eine deutliche Zeitschleife.

[Heiko J. (heiko_j)]

Also ich hab jetzt direkt hinter das Stackpointer verbiegen
eine Schleife gelegt, die eine weile laufen müsste. Ohne LTO lande ich 
am Breakpoint hinter der Schleife. Mit LTO lande ich direkt wieder im 
HardFault. Irgendwas ist echt oberfaul mit lto.

Debug compilerflags:
-mthumb -mcpu=cortex-m3 -Os -fno-builtin -ffunction-sections 
-fdata-sections -flto   -c -g -DUSE_STDPERIPH_DRIVER -Iinclude 
-ILibraries/CMSIS/CM3/CoreSupport 
-ILibraries/STM32F10x_StdPeriph_Driver/inc -mthumb -mcpu=cortex-m3 -Os 
-fno-builtin -ffunction-sections -fdata-sections -flto -MMD -MP -MF


Debug linkerflags:
-Os -Tsrc/stm32f107vct6_flash.ld -nostartfiles -Wl,--gc-sections -v 
-mcpu=cortex-m3 -mthumb -specs=nano.specs -specs=rdimon.specs -lc 
-lnosys -lc -u _printf_float -flto

      // Adjust sp       
    __asm__("ldr   sp, =__stack");

    unsigned int * ptrDst;
    unsigned int * ptrSrc;
    
    register uint32_t foo = 0;
    for (foo=0;foo < UINT32_MAX;foo++ ) {
        __asm__("nop");
    };

[Heiko J. (heiko_j)]

Kleine Ergänzung:

Packe ich die Schleife ganz an den Anfang des reset handler verhält es 
sich ganz genau gleich. Ohne LTO lande ich im Break, mit LTO im 
HardFault.

[Heiko J. (heiko_j)]

Sodele, bin jetz ein bisschen weiter gekommen mit dem Problem.

Mit LTO landet die komplette main im ResetHandler. Dadurch kommt LTO 
scheinbar mit dem verbiegen des Stackpointers im Startupcode des 
Resethandlers durcheinander.

_attribute_ ((externally_visible,used)) an die main ranklatschen hilft 
:-)

Jetzt funktioniert alles. Sogar mit LTO