arm-elf-gcc problem

Hi group,

I'm a newbie regarding the GNU ARM stuff. After many trials with intensive studying of the manuals for the gnu linker and assembler I have no more idea to solve the following problem:

I want to compile and link a very simple main.c with startup code and linker script (see below my sample files, its for ARM7TDMI). The linker, invoked by arm-elf-gcc, can't find the entry point symbol, which is referenced in my linker script and defined in the startup code as .global. The linker complains with:

arm-elf-gcc -nostartfiles -Wl,

-Wl,--script=my_linker_script -Wl,-cref cstartup.o main.o -o main.elf /gnuarm/bin/../lib/gcc-lib/arm-elf/3.3.3/../../../../arm-elf/bin/ld: warning: cannot find entry symbol __main; defaulting to 04000000

This is confusing because '__main' is defined as '.global' in the startup file. Did I miss something in the makefile? Hope anybody can give me hint.

Thanks in advance Steffen

The startup code fragment:


.include "../at91lib_gnu/periph/arm7tdmi/" .include "" /****************************** code entry point

******************************/ /* Define "__main" to ensure that C runtime system is not linked */ .global __main /* Exception vectors (before Remap) */


B InitReset /* reset */ undefvec: B undefvec /* Undefined Instruction */ swivec: B swivec /* Software Interrupt */ pabtvec: B pabtvec /* Prefetch Abort */ dabtvec: B dabtvec /* Data Abort */ rsvdvec: B rsvdvec /* reserved */ irqvec: B irqvec /* reserved */ fiqvec: B fiqvec /* reserved */

/* EBI Initialization Data */

InitTableEBI: .word EBI_CSR_0 .word EBI_CSR_1 .word EBI_CSR_2 .word EBI_CSR_3 .word EBI_CSR_4 .word EBI_CSR_5 .word EBI_CSR_6 .word EBI_CSR_7 .word 0x00000001 /* REMAP command */ .word 0x00000006 /* memory regions, standard read */

PtEBIBase: .word EBI_BASE /* EBI Base Address */

/* The reset handler before Remap From here, the code is executed from SRAM address Exporting labels used in other files



/* Load System EBI Base address and CSR0 Init Value


ldr r0, PtEBIBase ldr r1, InitTableEBI

/*- Speed up code execution by disabling wait state on Chip Select 0*/

str r1, [r0] bl __low_level_init

...and so on...

pretty simple main.c:

----------------------- int main(void) { int a,b; volatile int my_var;

a=10; b=20; my_var=a+b;

return 0; }

my linker script:



MEMORY { int_ram : org = 0x00000000, len = 8K /* internal RAM */ ram : org = 0x04000000, len = 1024K /* RAM at CS1 */ }

SECTIONS { .startup : { cstartup.o; *(.glue_7t); *(.glue_7); *(.rdata); *(.fini);

} > int_ram

.text : { main.o; *(.text); } > ram

.data : { *(.data); } > ram

.bss : { *(.bss) *(COMMON); } > ram }

my makefile:


CC = arm-elf-gcc AS = arm-elf-as

INC = INC += -I ../at91lib_gnu

ASM.FILES = ASM.FILES += cstartup.S

ASM.FLAGS += ASM.FLAGS += -mthumb-interwork ASM.FLAGS += -mcpu=arm7tdmi ASM.FLAGS += -gstabs

C.FILES = main.c

C.FLAGS += C.FLAGS += -c C.FLAGS += -g C.FLAGS += -mcpu=arm7tdmi C.FLAGS += -mthumb-interwork

L.FLAGS = L.FLAGS += -nostartfiles L.FLAGS += -Wl, L.FLAGS += -Wl,--script=my_linker_script L.FLAGS += -Wl,-cref

OBJ = OBJ += $(patsubst %.S,%.o,$(ASM.FILES)) OBJ += $(patsubst %.c,%.o,$(C.FILES))

%.o : %.S makefile $(AS) $(INC) $(ASM.FLAGS) $< -o $@

%.o : %.c makefile $(CC) $(INC) $(C.FLAGS) $< -o $@

all: $(OBJ)

exec: $(OBJ) $(CC) $(L.FLAGS) $(OBJ) -o main.elf

clean: rm *.o rm *.elf rm *.map

Reply to
Steffen Lutzmann
Loading thread data ...

Where did you get this script file?

For these kind of issues, I'd recommend you to join the GNUARM mailing list:

formatting link


-- PabloBleyerKocik pbleyer2004 /"Reliable software must kill people reliably." / -- Andy Mickel

Reply to
Pablo Bleyer Kocik

Thanks for the reply, Pablo.

Something wrong with that? Maybe my linker script is the reason that ld couldn't find the global symbols? This is my first try to write an own GNU linker script but I'm not sure whether I catched all the syntax in the right way. I oriented towards example scripts. I worked before with the ADS tools and, IMHO, the scatter file syntax of the ADS stuff is more descriptive than the GNU syntax. However, GNU is for free :-).

Thanks for that hint. Did this a few minutes ago...


Reply to
Steffen Lutzmann

Yes. Please read the SECTIONS command topic in the linker manual,

formatting link
If you are going to link for ELF you should be aware about how section names map for ELF objects. Also if you put the object name in a section without specifying the subsection, all the subsections will be inserted there. This is usually a mistake.

I guess most linker script syntaxes from all the providers are homeomorphisms between themselves, it just takes a while to know the permutations right ;^)


Reply to
Pablo Bleyer Kocik

Yes, got it before. I found some other examples and made some successful steps already. However, I should take this manual at home this weekend to read it once again slowly. But, I've less hope to get the time for that this weekend because of my five-months-old daughter :-)))

Thanks again for the tips Steffen

Reply to
Steffen Lutzmann

You could start by looking at the object file headers with objdump to see which sections are present in the compiled modules.

AFAIK, your script is missing many crucial ELF sections.

Are you targeting to have an ELF run-file or is the ultimate target a binary memory image to run stand-alone? Please note that an ELF file needs a pretty complicated loader to get it in.

Tauno Voipio tauno voipio @ iki fi

Reply to
Tauno Voipio


My first step is to try to make it run in the insight gdb simulator. The next step should be the download with our BDI2000 debugger to an evaluation board with an AT91M55800. This should be done with a run-file I think.

I did some projects with the ADS tools before (with my own makefiles, linker scripts etc. under cygwin). My programs ran successful from external flash on the board I mentioned above. But, it seems a little bit tough to port these former projects to the GNU environment. But I realize that the essential point is to understand the syntax of the GNU linker scripts in detail.


Reply to
Steffen Lutzmann

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.