Linkowanie projektu w GCC dla ARM: Błąd z FP w swi_handler.o vs main.out

Tue Jul 22, 2008 10:38 pm   

Witam!!

Dostaję taki oto komunikat przy próbie "budowy projektu" przy pomocy
GCC (z pakietu Yagarto):

arm-elf-ld: ERROR: swi_handler.o uses hardware FP, whereas main.out uses
software FP
arm-elf-ld: failed to merge target specific data of file swi_handler.o

Czyli problem przy linkowaniu, ale "wyróżnia się" tylko jeden plik ...
niestety, nie wiem nawet czym, bo co to znaczy to FP?? Floating point??
chyba nie .. dodam, że wszystkie pliki tworzę z tymi samymi flagami
przekazywanymi do kompilatora, dlatego nie rozumiem, czemu ten jeden
inaczej używa tajemniczego FP... Co dziwniejsze - takie zachowanie
obserwuje tylko na jednym komputerze, a drugim wszystko jest OK... a na
obu instalowalem DOKLADNIE TA SAMA WERSJE oprogramowania!! Co moze byc
nie tak?? PRzesyłam cały plik makefile ...

Pozdrawiam
Konop

PS Oczywiście make clean nie pomaga ;)

NAME = demo2378_blink_flash

CC = arm-elf-gcc
CXX = arm-elf-g++
LD = arm-elf-ld -v
AR = arm-elf-ar
AS = arm-elf-as
CP = arm-elf-objcopy
OD = arm-elf-objdump

CFLAGS = -I./ -c -fno-common -O0 -g
CXXFLAGS = -I./ -c -fno-common -O0 -g
AFLAGS = -ahls -mapcs-32 -o
LFLAGS = -Map main.map -Tdemo2378_blink_flash.cmd
CPFLAGS = -O binary
HEXFLAGS = -O ihex
ODFLAGS = -x --syms

all: test

clean:
-rm SPI_SSP0.o crt.lst main.lst fio.o irq.o crt.o swi_handler.o
swi_calls.o uart0.o target.o main.o main.out main.hex main.map main.dmp
main.bin

test: main.out
@ echo "...copying"
$(CP) $(CPFLAGS) main.out main.bin
$(OD) $(ODFLAGS) main.out > main.dmp
@echo "...building hex"
$(CP) $(HEXFLAGS) main.out main.hex
@echo "...creating main.lst file"
$(OD) -h -S main.out >main.lst

main.out: crt.o swi_handler.o swi_calls.o target.o fio.o irq.o main.o
uart0.o SPI_SSP0.o demo2378_blink_flash.cmd
@ echo "..linking"
$(LD) $(LFLAGS) -o main.out crt.o main.o SPI_SSP0.o uart0.o
swi_handler.o swi_calls.o target.o fio.o irq.o

target.o: target.c

$(CC) $(CFLAGS) target.c

fio.o: fio.c

$(CC) $(CFLAGS) fio.c

irq.o: irq.c

$(CC) $(CFLAGS) irq.c

crt.o: crt.s
@ echo "...assembling crt.S"
$(AS) $(AFLAGS) crt.o crt.s > crt.lst

swi_calls.o: swi_calls.c
$(CC) $(CFLAGS) swi_calls.c

swi_handler.o: swi_handler.S
@ echo "...assembling swi_handler.S"
$(AS) $(AFLAGS) swi_handler.o swi_handler.s > swi_handler.lst

uart0.o: uart0.c
@ echo "...compiling uart0.c file"
$(CC) $(CFLAGS) uart0.c

SPI_SSP0.o: SPI_SSP0.c
@ echo "...compiling SPI_SSP0.c file"
$(CC) $(CFLAGS) SPI_SSP0.c

main.o: main.c
@ echo "...compiling main.c file"
$(CC) $(CFLAGS) main.c

Wed Jul 23, 2008 12:35 pm   

On 22 Lip, 23:38, Konop <kono...@gazeta.pl> wrote:
[quote:52df145382]Czyli problem przy linkowaniu, ale "wyróżnia się" tylko jeden plik ...
niestety, nie wiem nawet czym, bo co to znaczy to FP?? Floating point??
chyba nie .. dodam, że wszystkie pliki tworzę z tymi samymi flagami
przekazywanymi do kompilatora, dlatego nie rozumiem, czemu ten jeden
inaczej używa tajemniczego FP...
[/quote:52df145382]
FP tutaj to właśnie floatig point...
Zauważ, że ten jeden plik masz w asemblerze (nielicząć crt.s, ale ten
raczej nie używa zmiennego przecinka) i w związku z tym używa innych
flag kompilacji.
Pakietu yagarto nie używałem, w gcc domyślnie jest hardware FP, ale,
teoretycznie, pakiet mógł zostac wybudowany z innymi flagami
domyślnymi.


[quote:52df145382]... Co dziwniejsze - takie zachowanie
obserwuje tylko na jednym komputerze, a drugim wszystko jest OK... a na
obu instalowalem DOKLADNIE TA SAMA WERSJE oprogramowania!! Co moze byc
nie tak??
[/quote:52df145382]
Przyszło mi jeszcze do głowy - porównaj zmienne środowiskowe na tych
komputerach. Może zostały gdzieś ustawienia z innego projektu
(CFLAGS ?). W make-u zmienne środowiskowe mają wyższy priorytet, niż
ustawienia w makefile-u.

Szeluś

Wed Jul 23, 2008 4:37 pm   

szelus@googlemail.com pisze:
[quote:5bf8c4842e]On 22 Lip, 23:38, Konop <kono...@gazeta.pl> wrote:
Czyli problem przy linkowaniu, ale "wyróżnia się" tylko jeden plik ...
niestety, nie wiem nawet czym, bo co to znaczy to FP?? Floating point??
chyba nie .. dodam, że wszystkie pliki tworzę z tymi samymi flagami
przekazywanymi do kompilatora, dlatego nie rozumiem, czemu ten jeden
inaczej używa tajemniczego FP...

FP tutaj to właśnie floatig point...
Zauważ, że ten jeden plik masz w asemblerze (nielicząć crt.s, ale ten
raczej nie używa zmiennego przecinka) i w związku z tym używa innych
flag kompilacji.
Pakietu yagarto nie używałem, w gcc domyślnie jest hardware FP, ale,
teoretycznie, pakiet mógł zostac wybudowany z innymi flagami
domyślnymi.


... Co dziwniejsze - takie zachowanie
obserwuje tylko na jednym komputerze, a drugim wszystko jest OK... a na
obu instalowalem DOKLADNIE TA SAMA WERSJE oprogramowania!! Co moze byc
nie tak??

Przyszło mi jeszcze do głowy - porównaj zmienne środowiskowe na tych
komputerach. Może zostały gdzieś ustawienia z innego projektu
(CFLAGS ?). W make-u zmienne środowiskowe mają wyższy priorytet, niż
ustawienia w makefile-u.

Szeluś
Hmm, okej, wiesz, ja nie bardzo się w tym wszystkim orientuję ;P... dla[/quote:5bf8c4842e]
mnie to całe gcc, makefile itp to totalna głupota ;P... ale nieważne
... wczoraj już nic mi się nie chciało z tym robić, dziś w firmie
pisałem dalej (tam to zawsze działało), wróciłem do domu i o dziwo -
działa bez zarzutu ;P... dlatego teraz nie będę na siłę szukał problemu,
skoro sam się rozwiązał ;P... a co do tego Floating Point - dziwi mnie
to dlatego, że plik, przez który było to całe zamieszanie, chyba nie
korzysta z FP ... Wyciąłem z niego komentarze i zamieszczam poniżej
.. ma to być włączanie i wyłączanie przerwan sprzętowych przez
przerwania programowe, plik nie jest mojego autorstwa. Patrzę i patrzę -
i FP nie widzę, choć baaaardzo bym chciał..

Ale wielkie dzięki za odpowiedź!! ....

Pozdrawiam
Konop

..equ SWI_IRQ_DIS, 0
..equ SWI_IRQ_EN, 1
..equ SWI_FIQ_DIS, 2
..equ SWI_FIQ_EN, 3

..equ I_Bit, 0x80
..equ F_Bit, 0x40

..arm
..text

SoftwareInterrupt:
LDR R0, [LR, #-4] /* get swi instruction code (ARM-mode) */
BIC R0, R0, #0xff000000 /* clear top 8 bits leaving swi "comment
field"=number */
CMP R0, #4 /* range check */
LDRLO PC, [PC, R0, LSL #2] /* get jump-address from table */
MOVS PC, LR /* if out of range: do nothing and return */

SwiFunction:
..word IRQDisable
..word IRQEnable
..word FIQDisable
..word FIQEnable

IRQDisable:
MRS R0, SPSR
ORR R0, R0, #I_Bit
MSR SPSR_c, R0
MOVS PC, LR

IRQEnable:
MRS R0, SPSR
BIC R0, R0, #I_Bit
MSR SPSR_c, R0
MOVS PC, LR

FIQDisable:
MRS R0, SPSR
ORR R0, R0, #F_Bit
MSR SPSR_c, R0
MOVS PC, LR

FIQEnable:
MRS R0, SPSR
BIC R0, R0, #F_Bit
MSR SPSR_c, R0
MOVS PC, LR

Wed Jul 23, 2008 6:00 pm