This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Possible bug; code-block vanishes when adding one assembler-instruction.
- From: Jens Bauer <jens-lists at gpio dot dk>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 7 May 2013 09:18:21 +0200
- Subject: Possible bug; code-block vanishes when adding one assembler-instruction.
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.
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 if I need to provide more information.
(Note: This is my third time I'm trying to send this email; I had so much problems [on all GNU lists] with being blocked, because I had no reverse DNS.)
Love
Jens