Possible bug; code-block vanishes when adding one assembler-instruction.

[Jens Bauer <jens-lists at gpio dot dk>]

Due to my confusion overwhelming me, I sent this to the gcc list by mistake.
I was recommended to resend it to the binutils list, so hereby done; I added a little extra, though.

I'm using a GCC toolchain similar to Yagarto for making code for the LPC1768 microcontroller.

My gcc is version 4.7.2, my binutils is version 2.23.1

To make parts of my code run faster (a timer interrupt to be exact), I've used a modified linker script, so that I get a '.fastcode' section.
The linker script I copied can be found here:
<http://openlcb.sourceforge.net/trunk/scratchpads/dgoodman/OpenLCB_Template/makesection/LPC17xx.ld>

My code is as follows:

        .syntax     unified
        .section    .fastcode
        .global     interrupt
        .func       interrupt
        .type       interrupt,%function
        .thumb_func
interrupt:
    
;//     str         r1,[r0, #0]   /* offending line */
        movw        r0,#0x1234
        movt        r0,#0x5678
        bx          lr
    
        .pool
        .endfunc
        .size       interrupt, . - interrupt
    
        .end


Now as it is there, everything's correct.

$ tail -n 6 Fastcode-test.hex
:100400001C0400001C040000200400001847C04623
:10041000F8B5C046F8BC08BC9E46704751010000C4
:10042000F8B5C046F8BC08BC9E46704721010000E4
:0C04300041F23420C5F2786070470000F3           <-- This is my routine, which should be located in RAM
:04000003000001D91F
:00000001FF

Now, when I enable the line 'str r1,[r0, #0]', and I do a 'make clean; make', I get this:
$ tail -n 6 Fastcode-test.hex
:1003F0000DF8A642F9D170BC01BC00471C040000F6
:100400001C0400001C040000200400001847C04623
:10041000F8B5C046F8BC08BC9E46704751010000C4
:10042000F8B5C046F8BC08BC9E46704721010000E4
:04000003000001D91F
:00000001FF


This has been driving me crazy, and it took a few days to nail it down.

If I have the 'str r1,[r0, #0]' line disabled and replace the 'movw' / 'movt' instructions with this...
        .rept 64
        movt        r0,#0x5678
        .endr

...then I still get the code in the .hex file.

-But if I insert just one of the following lines, the function disappears from the .hex file:

        ldr         r0,=(LPC_GPIO2 + FIOPIN)
        ldr         r1,[r0]
        str         r1,[r0]

Now, one interesting thing is that the disassembly looks just fine to me, so does the linker map.
I'm using gcc -x assembler-with-cpp for assembling, and g++ for linking.
Since the disassembly looks fine and the linker map looks fine and the hex file looks wrong, I suspect that it has to do with objcopy.

This is the objcopy part of my Makefile:
$(PROJECT).hex: $(PROJECT).elf
	$(OBJCOPY) -R .stack -O ihex $(PROJECT).elf $(PROJECT).hex

Here's my linker part of my Makefile:

$(PROJECT).elf: $(LSCRIPT) $(OBJECTS)
	$(LD) $(LDFLAGS) $(LDOBJECTS) $(OBJECTS) -o $(PROJECT).elf
	$(SIZE) $(PROJECT).elf

PROJECT=Fastcode-test
OBJCOPY=arm-none-eabi-objcopy
LDFLAGS = -mcpu=cortex-m3 -mthumb -O2 -Wl,-Map=$(PROJECT).map,--cref,--gc-sections -lc -lm -lgcc -lstdc++  -T$(LSCRIPT)


This could be a bug in my Makefile, my linker script, in my source file or in how I compiled gcc/binutils.
-But as there is a chance it could be in gcc or binutils, I'd like to ask here - does anyone have a clue of what's going on in this case ?

Please let me know what other information I need to provide.


Love
Jens