简体   繁体   中英

-Os flag necessary to make general purpose register behave normally

I am currently working with a TI EK-LM4F120XL board. This board contains a Cortex-M4F cpu. I am using the following chain:

ARM GCC None EABI https://launchpad.net/gcc-arm-embedded/4.8/4.8-2014-q2-update

And the following debugger:

OpenOCD http://openocd.sourceforge.net/

The problem is that I need to use the -Os flag to prevent strange behaviour. An example, using code provided by TI:

Default linker script:

MEMORY
{
    FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x00040000
    SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00008000
}

SECTIONS
{
    .text :
    {
        _text = .;
        KEEP(*(.isr_vector))
        *(.text*)
        *(.rodata*)
        _etext = .;
    } > FLASH

    .data : AT(ADDR(.text) + SIZEOF(.text))
    {
        _data = .;
        *(vtable)
        *(.data*)
        _edata = .;
    } > SRAM

    .bss :
    {
        _bss = .;
        *(.bss*)
        *(COMMON)
        _ebss = .;
    } > SRAM
}

The startup_gcc.c file: pastbin, because the file is large

And a very simple blinker:

int
main(void)
{
    volatile unsigned long ulLoop;

    //
    // Enable the GPIO port that is used for the on-board LED.
    //
    SYSCTL_RCGC2_R = SYSCTL_RCGC2_GPIOF;

    //
    // Do a dummy read to insert a few cycles after enabling the peripheral.
    //
    ulLoop = SYSCTL_RCGC2_R;

    //
    // Enable the GPIO pin for the LED (PF3).  Set the direction as output, and
    // enable the GPIO pin for digital function.
    //
    GPIO_PORTF_DIR_R = 0x08;
    GPIO_PORTF_DEN_R = 0x08;

    //
    // Loop forever.
    //
    while(1)
    {
        //
        // Turn on the LED.
        //
        GPIO_PORTF_DATA_R |= 0x08;

        //
        // Delay for a bit.
        //
        for(ulLoop = 0; ulLoop < 200000; ulLoop++)
        {
        }

        //
        // Turn off the LED.
        //
        GPIO_PORTF_DATA_R &= ~(0x08);

        //
        // Delay for a bit.
        //
        for(ulLoop = 0; ulLoop < 200000; ulLoop++)
        {
        }
    }
}

Nothing special, all default code as created by TI. Compilation and linking commands:

~/gcc-arm-none-eabi/bin/arm-none-eabi-gcc blink.c startup_gcc.c -g -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -ffunction-sections -fdata-sections -Os -MD -std=c99 -Wall -pedantic -DPART_LM4F120H5QR -c -I/home/jacko/git/jackoOS/stellaris-exe  -DTARGET_IS_BLIZZARD_RA1
~/gcc-arm-none-eabi/bin/arm-none-eabi-ld -T blink.ld --entry ResetISR -o a.out startup_gcc.o blink.o --gc-sections

As you can see the compiling command contains a -Os param. If I add this to the command everything works fine, but if I remove it, register 7 starts to act very weird:

(gdb) monitor reg
===== arm v7m registers
(0) r0 (/32): 0x00000000
...
(7) r7 (/32): 0x200000F0
...
(13) sp (/32): 0x200000F0
...
(17) msp (/32): 0x200000F0
...
===== Cortex-M DWT registers
...
(36) dwt_3_function (/32)
(gdb) cont
...
(gdb) monitor reg
===== arm v7m registers
...
(7) r7 (/32): 0x200000E0
...
(13) sp (/32): 0x200000E0
...
(17) msp (/32): 0x200000E0
(18) psp (/32): 0x00000000
...
===== Cortex-M DWT registers
...
(36) dwt_3_function (/32)

(full dump can be found here )

R7 has the same value as the SP (MSP = active SP)! Why would it do that?

If I try to write to R7 with:

MOV     R7, R0

The program just crashes into a hard fault.

So, why is this -Os flag so important? Why does R7 act so weird without it?

GCC uses R7 as FP under thumb mode. Try "-fomit-frame-pointer" if you are not using any optimization flag to avoid that behavior.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM