#20429 - NitroSR - Tue May 11, 2004 5:43 am
I am experimenting with WinterMute's DevkitARM and Jeff's Lnkscript/crt0.s files. Things are working relatively smooth, until I try to compile my test.c file with the -mthumb option turned on. Doing so causes my emulator to freeze requiring me to kill the process. The test.c isn't doing much more than writing some test values to EWRAM so I can make sure it's doing anything, so i don't think it's important. I have included a copy of the makefile, however.
What could be causing this freezing? Have I missed something?
| Code: |
PREFIX = arm-elf-
GCC = $(PREFIX)gcc
AS = $(PREFIX)as
LD = $(PREFIX)ld
OBJCOPY = $(PREFIX)objcopy
CFLAGS = -O2 -mthumb-interwork -mthumb
LDFLAGS = -T lnkscript
ASFLAGS = -mthumb-interwork
all: test.gba
crt0.o: crt0.s
$(AS) $(ASFLAGS) crt0.s -o crt0.o
test.o: test.c
$(GCC) $(CFLAGS) -c test.c -o test.o
test.elf: test.o crt0.o
$(LD) $(LDFLAGS) test.o crt0.o -o test.elf
test.gba: test.elf
$(OBJCOPY) -O binary test.elf test.gba
clean:
rm *.o
rm *.elf
rm *.gba
|
#20434 - Cearn - Tue May 11, 2004 8:35 am
Have you tried adding -mthumb-interwork -mthumb to the LDFLAGS? For some reason that worked in my case. Also, it might help to put ctr0.o first in the list of the to-link objects; it is boot code after all.
#20446 - NitroSR - Tue May 11, 2004 3:37 pm
It appears as if changing the order of the .o files has resolved the issue. Apparently the linker priorities based on architecture and thus did not give me any problem with order before.
Thanks.
#20509 - Dracula-X - Wed May 12, 2004 9:18 am
If I'm not mistaken (you'll have to check with Wintermute) there is some sort of problem using jeff's bog standard crt0. The default crt0's in DevkitARM are proper for the gba.
#20517 - creepy - Wed May 12, 2004 12:43 pm
I had the same problem. Switching the order of the .o files (crt0.o first) also solved the problem.
But shouldn't the lnkscript link the crt0.o in? Will try that this evening.
Another problem I have with this devkit is that I can't link in the standard libs (de math lib in this case). A -lm added to the linker options (and using math.h in the source) gives me a lot of warning messages about the math libs not compiled with thumb-interworking.
Disabling thumb-interworking for my object files and crt0.o gives complaints about the crt0.o not being compiled with thumb-interworking.
My other devkit (compiled from source with a makefile from http://www.geocities.com/xgoatboyx/index.html ) I use in Linux does not have this problem..
Btw, can the devkitarm_r6 be used without a linkscript or extra crt0.o in Linux? Most of the tutorials use a make.bat which only compiles and links the object files. No references to a lnkscript or crt0.o/s are given. I can confirm that this does not work in Linux with the devkitarm_r6 and my other devkit. In both cases I use Jeff's crt0.s and lnkscript
#20519 - Cearn - Wed May 12, 2004 1:51 pm
AFAIK the linkscript just links together what you give to it. Whether or not this includes crt0.o depends mainly on whether you invoke ld directly or not. If you use gcc, it'll link standard libs automatically, as well as crt0.o ... unless you use the -nostartfiles option. When using ld directly, you have to write down everything yourself. At least that's how devkit Advance uses it; for devkitARM you need to use -specs=gba.specs or -specs=gba_mb.specs for multiboot programs to link crt0.o into your binary.
About thumb-interworking:
You need this flag to get ARM code to work with THUMB code properly. I'm not exactly sure what can go wrong if you omit it, but using the flag seems to be the Right Thing (TM) to do, so you'd better use it. The reason you don't get many complains from, say, devkit Advance about this is probably because it has all the libraries and boot-files in quadruplet!! to account for all possible cases. I can't check right now, but I think devkitARM only has one.
The standalone crt0.o and lnkscript are usually only used for interrupt support, which in turned off in the default crt0.o. devkitARM uses a different solution to interrupt support, namely a separate interrupt handler (single_ints.s), which can be assembled and linked to the project without messing with crt0.S. It's included in the libgba that you can find in the samples section on devkitARM's homepage.
So with devkitARM there's never any real need to use a separate crt0.o and linkscript, the default (and thus unmentioned) ones will do fine. All you really need to do is use the -specs flags I mentioned earlier (and -mthumb-interwork). At least, that's ow it works on Windows, don't see why the Linux case would be different here.
Btw, http://forum.gbadev.org/viewtopic.php?t=2929 is a similar topic to this one, I suggest reading it as well if you haven't already.
#20522 - creepy - Wed May 12, 2004 2:08 pm
Ah, so if I use the -specs option it'll be fine. I could not find this information on www.devkit.tk.
Also using gcc directly to compile and link my source did not work here without libdga. I didn't want to use that lib.
I'll try using the -specs option and see if that'll work.
#20524 - Cearn - Wed May 12, 2004 2:35 pm
I know what you mean. The only place it's mentioned right now is in the makefiles of the samples.
#20544 - creepy - Wed May 12, 2004 9:22 pm
Hmm.. great. All examples are written for Windows and use absolute paths.
When using the -specs=gba.specs options it complain about not finding an entry symbol
| Quote: |
arm-elf-ld: warning: cannot find entry symbol cs=gba.specs; defaulting to 00008000
|
Afcourse the resulting file cannot be used.
The Makefile I use:
| Code: |
PREFIX = arm-elf-
GCC = $(PREFIX)gcc
AS = $(PREFIX)as
LD = $(PREFIX)ld
OBJCOPY = $(PREFIX)objcopy
CFLAGS = -Wall -O2 -mthumb -mthumb-interwork -mcpu=arm7tdmi -mtune=arm7tdmi
LDFLAGS = -specs=gba.specs
all: test.gba
.c.o:
$(GCC) $(CFLAGS) -c $<
test.elf: test.o
$(LD) $(LDFLAGS) test.o -o test.elf
test.gba: test.elf
$(OBJCOPY) -O binary test.elf test.gba
clean:
@rm *.o *.elf *.gba
|
Using crt0.s and lnkscript from Jeff seems to work fine here though, dispite the mentioned troubles with it and this devkit. Haven't tested it with interrupts though.
#20546 - Cearn - Wed May 12, 2004 9:46 pm
| creepy wrote: |
arm-elf-ld: warning: cannot find entry symbol cs=gba.specs; defaulting to 00008000
|
Strange that it shouldn't work. Even stranger is that it complains about "cs=gba.specs" and not "specs=gba.specs", as if the "spe" got snipped off somehow.
Anyway, what happens if you also include the interworking flag? Or compile with gcc instead of ld? It could be that you also need to set some paths when you use ld.
I have been able to get a working compile with something like
| Code: |
arm-elf-gcc -mthumb-interwork -c first.c
arm-elf-gcc -specs=gba.specs -mthumb-interwork -o first.elf first.o
arm-elf-objcopy -O binary first.elf first.gba
|
I'll try if I can break it to reproduce your error.
#20548 - wintermute - Wed May 12, 2004 11:03 pm
| creepy wrote: |
| Hmm.. great. All examples are written for Windows and use absolute paths. |
actually they're not written for windows, the examples will work quite happily in linux if the paths are changed to suit your installation. Absolute paths are used in the makefiles to allow building to take place outside the source directory.
| Quote: |
When using the -specs=gba.specs options it complain about not finding an entry symbol
arm-elf-ld: warning: cannot find entry symbol cs=gba.specs; defaulting to 00008000
Afcourse the resulting file cannot be used.
|
Don't call arm-elf-ld directly use arm-elf-gcc to link. -specs is a gcc switch and doesn't work with ld. Never use ld directly, gcc sets a lot of options which are needed to find libraries. You should also be passing the -mthumb & -mthumb-interwork flags to the linker at this point. These switches tell gcc which set of libraries to link against, it will default to -marm.
| Code: |
PREFIX = arm-elf-
GCC = $(PREFIX)gcc
AS = $(PREFIX)as
LD = $(PREFIX)ld <----- change this to gcc
OBJCOPY = $(PREFIX)objcopy
CFLAGS = -Wall -O2 -mthumb -mthumb-interwork -mcpu=arm7tdmi -mtune=arm7tdmi
LDFLAGS = -specs=gba.specs <----- add -mthumb -mthumb-interwork here too
all: test.gba
.c.o:
$(GCC) $(CFLAGS) -c $<
test.elf: test.o
$(LD) $(LDFLAGS) test.o -o test.elf
test.gba: test.elf
$(OBJCOPY) -O binary test.elf test.gba
clean:
@rm *.o *.elf *.gba
|
| Quote: |
Using crt0.s and lnkscript from Jeff seems to work fine here though, dispite the mentioned troubles with it and this devkit. Haven't tested it with interrupts though. |
the most recent version of devkitARM doesn't have trouble - that was one of the reasons for reverting from binutils 2.15.
It would have been helpful if you'd directed your questions to the devkitARM mailing list - http://groups.yahoo.com/group/devkitARM/
and no, you don't have to have a yahoo account to use the list - read the about page on devkit.tk :)
edit: aha I see you did - I'll answer there too
#20575 - creepy - Thu May 13, 2004 8:49 am
Ah, so thats it. Just call gcc to link instead of ld. Thanx.
Compiling and linking works like a charm now. I'll have to be back @ home to see if the rom works, but I expect that is does.