kann arm-none-eabi-ld mit thumb umgehen?

[W.S. (Gast)]

Hallo zusammen,

heute hab ich mal ne Frage an die GCC-Experten.
Es geht um das Projekt "Lernbetty" hier im Forum. Normalerweise benutzt 
ich den Keil, aber bei der Lernbetty will ich es wissen, daß es auch mit 
GCC geht, weswegen ich das Ganze auch mit GCC übersetzen will. Mein Ziel 
ist es, die einzelnen Teile (Assembler, Compiler, Linker, Objcopy..) 
direkt ohne Make usw, aufgerufen zu kriegen, so daß das Gewünschte 
fehlerfrei dabei herauskommt. (Ratschläge wie "nimm Eclipse" sind hier 
nicht hilfreich)

Also:
Bei der BettyBase geht alles klar, die läuft sowohl per Keil als auch 
per GCC, aber bei den Betty-Apps gibt es schwerste Probleme mit dem 
Linker, der partout zwischen zwei Funktionen, die beide thumb code sind, 
seine Linker-Stubs einbauen will und dabei den Totalabsturz verursacht.

Näheres hab ich im angehängten PDF erläutert. Die in der Distri 
enthaltene Doku zum Linker hab ich mittlerweile x mal durchgelesen, 
finde aber zu diesem speziellen Thema nix wirklich hilfreiches - aber 
die ist ja auch extrem allgemein gehalten und will alle erdenklichen uC 
abdecken.

Wie kriegt man den Linker dazu, zwischen thumb und thumb KEINEN Stub zu 
setzen?

Hat jemand eine Rat?

W.S.

[Jim M. (turboj)]

Du musst auch dem Linker die MCU Architektur mitteilen, und dass Du 
Thumb Code haben möchtest.

Es ist übrigens bei GCC am Einfachsten, LD nicht direkt aufzurufen 
sondern GCC als Frontend auch fürs Linken zu benutzen - bei Dir also 
"arm-none-eabi-gcc".

[W.S. (Gast)]

Jim Meba schrieb:
> Du musst auch dem Linker die MCU Architektur mitteilen, und dass Du
> Thumb Code haben möchtest.

Das will ich ja gern glauben, bloß wie verklickere ich es dem Linker?

Sowohl Assembler als auch Compiler erzeugen ja thumb code und ich bilde 
mir ein, daß in den Objektfiles auch drinstehen müßte, um was für Code 
es sich handelt.

Der Linker scheint das ja auch zu kapieren, immerhin sieht man im 
Linker-Mapfile, daß er die diversen thumb-Funktionen auf Thumb-Adressen 
(also im 16 Bit Raster) angeordnet hat.

Wie sag ich es ihm denn nun, daß es sich auch ganz wirklich um thumb 
code handelt? In der Doku hab ich es nicht finden können.

W.S.

[Karsten F. (Firma: von Dänemark) (bingo600)]

@WS

I have just been through somewhat the same with the Boop firmware
http://bettyhacks.com/forum/index.php?topic=285.msg2078#msg2078

+++ Makefile.local.linuxARM  (working copy)
@@ -8,12 +8,18 @@
 #####
 ###############################################################

-ARMBASE = /opt/arm-elf
+ARMBASE = ${HOME}/arm/arm-gcc/arm-elf
 INCLUDEPATH = $(ARMBASE)/include
-LIBPATH = $(ARMBASE)/lib/gcc/arm-elf/4.1.1/interwork
+#LIBPATH = $(ARMBASE)/lib/gcc/arm-elf/4.1.1/interwork
+#LIBPATH = .
 ARMPATH = $(ARMBASE)/bin
 TOOLPREFIX = arm-elf-
 LPCTOOL = lpctool -d /dev/ttyUSB0
 OPENOCD = openocd -f betty.cfg -f interface/parport.cfg

+LD = $(ARMPATH)/$(TOOLPREFIX)gcc
+
+#LDFLAGS = -Tlpc2220_rom.ld -Map boop.map
+LDFLAGS = -nostartfiles -mthumb-interwork -Xlinker -Map -Xlinker 
boop.map -Tlpc2220_rom.ld
+
 ######################## EOF ##################################


The main tricks are
1: Use GCC as linker
LD = $(ARMPATH)/$(TOOLPREFIX)gcc

2: Tell the linker about the architecture (I need to use thumb-interwork 
libs)
LDFLAGS = -nostartfiles -mthumb-interwork -Xlinker -Map -Xlinker 
boop.map -Tlpc2220_rom.ld


I had to use -nostartfiles , but i'm not sure you'd need that.

If you add : -Wl,--verbose
To the LDFLAGS you will get the full linker searchlist and parms shown 
during linking , can be usefull when debugging what libs are linked in.

/Bingo  Dänemark

[W.S. (Gast)]

Karsten F. schrieb:
> The main tricks are..

Hi Karsten,

thanks a lot, but it is not a problem with the libraries. The kernel of 
the problem is, that the linker installs a stub between two thumb 
functions. The linker already knows both functions, he has already 
loaded all object files and also the libraries.

Meanwhile I have found out by experiments a kind of "cooking recipe" to 
force the linker to do what I want from him. It works but such kind of 
solutions are rather disappointing, because they rely on things, which 
never have been properly documented. Now knowing this I understand, why 
lots of software writers always copy makefiles, linkfiles and so on from 
one old project to a next new project.

btw: maybe you are interested: 
"Beitrag "die Betty-Fernbedienung von Pollin als ARM-Eval Board"; it's a nice toy..

kind regards
W.S.

[Karsten F. (Firma: von Dänemark) (bingo600)]

I just had a look , seems like a nice project.

But why on earth is there no makefile ?

I'm on linux , and find a ".bat" file extremely useless :-)

Karsten

[ble, Bol (Gast)]

>I'm on linux , and find a ".bat" file extremely useless

And you don't have a DOS shell on your Linux box?

[ansel (Gast)]

ble, Bol schrieb:
> And you don't have a DOS shell on your Linux box?

Why would one? It would be the wrong tool for anything one would want to 
do with a Unix-like system.

Especially now that most PCs have more than one cpu. makefiles really 
shine because one can just add a -j4 and make will run compiler 
instances safely in parallel as it knows what targets depend on another.

Using batchfiles for compilation really looks like driving in screws 
with a hammer.

[W.S. (Gast)]

Karsten F. schrieb:
> I'm on linux , and find a ".bat" file extremely useless :-)

sorry, but I disagree. You only need to convert a simple .bat into a 
simple shellscript. But if you want to have a makefile, then write it 
for your pleasure. For me - on Windows - is am makefile the most 
annoying file I can imagine. The same is with specialized files for all 
those different IDE's.

You linux users always believe, that there is nothing other than GCC in 
the world - what a mistake.

W.S.

[ansel (Gast)]

W.S. schrieb:
> You linux users always believe, that there is nothing other than GCC in
> the world - what a mistake.

Yay, a prejudice contest.  I guess then it makes perfect sense
for windows users to use batch files for compilation.  The
declarative language of Make probably overexerts them, and
unnecessarily re-compiling object files despite unchanged source
is just the resource-wasting incarnation of their
throwing-money-at-problems-instead-of-thinking attitiude.

[Karsten F. (Firma: von Dänemark) (bingo600)]

W.S. schrieb:
> Karsten F. schrieb:
>> I'm on linux , and find a ".bat" file extremely useless :-)
>
> sorry, but I disagree. You only need to convert a simple .bat into a
> simple shellscript. But if you want to have a makefile, then write it
> for your pleasure. For me - on Windows - is am makefile the most
> annoying file I can imagine. The same is with specialized files for all
> those different IDE's.

The idea of the makefile is that it if made correct would be quite 
universal, and usefull on all OS'es.


>
> You linux users always believe, that there is nothing other than GCC in
> the world - what a mistake.
>
> W.S.

Well not everyone can afford a commercial version of Keil , or have one 
at the job.
Seems a bit silly to have a cheap develboard, and a very expensive 
compiler.

Well WS thanx for the project intro.

Let me know if you need a linux intro at some time.


Karsten

[W.S. (Gast)]

Karsten F. schrieb:
> Well not everyone can afford a commercial version of Keil , or have one
> at the job.

I know.
This is the reason for the SVC-wrappers in the Betty-Apps, because GCC 
cannot handle SVC's. Also the doubled startup codes, because GAS needs a 
different source notation. Also all the other measures to make the code 
compileable with both toolchains, because GCC does not understand some 
pragmas etc.

And if you look carefully, then you can see the binaries, I made with 
GCC (yagarto edition) by simple batchfiles. I do expect, that a linux 
user is capable to write a simple shell script to invoke the tools 
properly. Besides of this the whole system is modular. So everybody can 
use the BettyBase without any need to recompile it.

The LernBetty is a good basis - but do not expect me to provide some 
kind of "land of milk and honey", where people only need to open their 
mouth for self flying roasted pigeons.



> Seems a bit silly to have a cheap develboard, and a very expensive
> compiler.
Seems a bit silly to have only a sketchy glance on the files - right?

btw: we are looking for someone to translate the manual - in case a user 
does not understand german language...

W.S.

[temp (Gast)]

Irgendwie habt ihr es geschafft mich neugierig zu machen. Auch im 
aktuellen gcc-arm Thread.

Ich denke du hast ganz am Anfang nur die Funktionen im asm-File falsch 
declariert.

               .global FillLanes
               .thumb_func
FillLanes:     PUSH  {LR}
               SVC    9
         POP   {PC}

bei dir fehlt das Schlüsselwort .thumb_func, das ist nicht das selbe wie 
.thumb.

Im Gesamt-Listing
(mit arm-none-eabi-objdump -D BettyApp.elf > betty.list erzeugt)
sieht man es dann deutlich. Ich habe nur die Funktion FillLanes
angepasst. Hoffe das hilft.

82000054:  b537        push  {r0, r1, r2, r4, r5, lr}
82000056:  2020        movs  r0, #32
82000058:  f000 f866   bl  82000128 <FillLanes>
8200005c:  f000 f840   bl  820000e0 <__LichtEin_from_thumb>
82000060:  2128        movs  r1, #40  ; 0x28
82000062:  4a1a        ldr  r2, [pc, #104]  ; (820000cc <main+0x78>)
82000064:  2336        movs  r3, #54  ; 0x36
82000066:  200a        movs  r0, #10

Die Funktion FillLanes wird direkt angesprungen und der Linker-Stub 
entfällt.