This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Second, I have several questions about GCC / GAS / LD and I hope these questions have not been asked before...
I am working with GCC 2.7.2.2 configured as a cross-compiler on a Sun host (but also on a PC host thanks to canadian cross compile) and a motorola CPU32 target corresponding to m68k-none-aout in GCC jargon.
My first problem was when compiling libgcc due to an optimized "tstl a4" incorporated in _floatdixf : I have seen some unofficial patches but I hope next version of GCC will suppress this bug.
My second problem was that tst[bwl] definition in binutils/opcodes/m68k-opc.c is not correct instead of :
{"tstb", one(0045000),
one(0177700), ";b", m68020up|cpu32|mcf5200 },
{"tstb", one(0045000),
one(0177700), "@b", m68000up },
{"tstw", one(0045100),
one(0177700), "*w", m68020up|cpu32|mcf5200 },
{"tstw", one(0045100),
one(0177700), "@w", m68000up },
{"tstl", one(0045200),
one(0177700), "*l", m68020up|cpu32|mcf5200 },
{"tstl", one(0045200),
one(0177700), "@l", m68000up },
I think, it should be :
{"tstb", one(0045000),
one(0177700), ";b", m68020up|mcf5200 },
{"tstb", one(0045000),
one(0177700), "@b", m68000up },
{"tstw", one(0045100),
one(0177700), "*w", m68020up|mcf5200 },
{"tstw", one(0045100),
one(0177700), "@w", m68000up },
{"tstl", one(0045200),
one(0177700), "*l", m68020up|mcf5200 },
{"tstl", one(0045200),
one(0177700), "@l", m68000up },
My next problem was that I cannot use the CPU32 special instructions. I have tried the MIT and the MOTOROLA notation but no way, it allways answers :
Error: operands mismatch -- statement `tblu.l a2,d2' ignored
I fixed by using directly the opcode but is there any correct solution ?
Another problem was the generation of position independent code for this target. Is there any solutions which is not using 68020 addressing mode.
My last problem is the creation of some "org" like macro for assembler. I don't want to modify definitively the location counter as "org" does in GAS but instead manipulate data structure like the following :
org
0
H.pc1 lo.l 1
H.pc2 lo.l 1
org
4 Stack Offset Definition
S.a5 do.l 1 caller's a5
S.a6 do.l 1 caller's a6
S.func do.w 1 trap function code
S.vect do.w 1 vector number
S.pc do.l 1 return pc
which would give the following value :
H.pc1 = 0
H.pc2 = 4
S.a5 = 4
S.a6 = 0
S.func = -4
S.vect = -6
S.pc = -8
Thanks in advance for your help,
-- Olivier Carmona Assistant de Recherche au Laboratoire de Micro-Informatique IN-F-132, LAMI-EPFL, 1015 Lausanne, Suisse http://diwww.epfl.ch/lami/team/carmona
Configuration de binutils :
./configure --target=m68k-none-aout --prefix=/home/new_gcc68k/binutils
Configuration de gcc :
./configure --target=m68k-none-aout --prefix=/home/new_gcc68k
mv /home/new_gcc68k/binutils/m68k-none-aout /home/new_gcc68k
Mis dans /usr/local/m68k=none-aout tout le necessaire
Pour lire les fichiers assembleurs generes par l'ancien compilateur C (sun2-gcc) :
as --register-prefix-optional -o essai.o essai.s
Il est possible de compiler avec une virgule fixe grace l'option -msoft-float dans le cas ou l'unite flottante n'est pas disponible.
Cette version compile aussi en C++.
Mais ou se trouve les crt0.o ?
-fPIC : Option GCC pour Position Independent Code ? marche sur 68020 pas 68000 ou 68010
-m68332 = -m68020 + -m68332 pb avec les tstl a3
-m68302 = -m68000 + -m68302
Modif de insn-output.c pour que tstl a0 soit supprime meme si 68020
Bug : supprimer _floatdixf de la librairie libgcc2.a (dans Makefile) en fait genere un tstl a4 indesirable pour le 68000.
autre solution (ne marche pas) :
For some strange reason GCC 2.7.2.x generates bad assembler code
for the M68000 during optimization. Try adding this flag to the
compiler make process:
make TARGET_LIBGCC2_CFLAGS=-oO
Modifie dans binutils/opcodes/m68k-opc.c tst[bwl] valable pour 6820up & mfc500 & cpu32:
{"tstb", one(0045000), one(0177700), ";b", m68020up|cpu32|mcf5200 },
{"tstb", one(0045000), one(0177700), "@b", m68000up },
{"tstw", one(0045100), one(0177700), "*w", m68020up|cpu32|mcf5200 },
{"tstw", one(0045100), one(0177700), "@w", m68000up },
{"tstl", one(0045200), one(0177700), "*l", m68020up|cpu32|mcf5200 },
{"tstl", one(0045200), one(0177700), "@l", m68000up },
au lieu de :
{"tstb", one(0045000), one(0177700), ";b", m68020up|mcf5200 },
{"tstb", one(0045000), one(0177700), "@b", m68000up },
{"tstw", one(0045100), one(0177700), "*w", m68020up|mcf5200 },
{"tstw", one(0045100), one(0177700), "@w", m68000up },
{"tstl", one(0045200), one(0177700), "*l", m68020up|mcf5200 },
{"tstl", one(0045200), one(0177700), "@l", m68000up },
Modif dans Makefile de GCC :
LIBGCC2_INCLUDES = -I/usr/include
CC = gcc
TARGET_LIBGCC2_CFLAGS =-oO
CFLAGS = -g -DMOTOROLA -DUSE_GAS
-fPIC impossible car genere des jbsr label,a1 : Label Sun (cf config/m68k/m68k.md) definir MOTOROLA et USE_GAS dans C_FLAGS
Modif de *crt0.s pour supprimer le jump. et ajout des variables ROF_DATA, ROF_TEXT et ROF_BSS corectement mises plus suppression de _rof_data, _rof_text et _rof_bss en lieu et place.
Seul elf supporte l'ecriture en PIC. D'ou la recompil de binutils puis gcc :
./configure --target=m68k-none-elf --prefix=/home/new_gcc68k/binutils
./configure --target=m68k-none-sysv4 --prefix=/home/new_gcc68k
PIC Information :
;; For PIC calls, in order to be able to support
;; dynamic linker LAZY BINDING, all the procedure calls need to go
;; through the PLT (Procedure Linkage Table) section in PIC mode.
;;
;; PIC calls are handled by loading the address of the function into a
;; register (via movsi), then emitting a register indirect call using
;; the "jsr" function call syntax.
;;
;; When outputting MIT syntax (e.g. on Suns), we add a bogus extra
;; operand to the jbsr statement to indicate that this call should
;; go through the PLT (why? because this is the way that Sun does it).
;;
;; We have different patterns for PIC calls and non-PIC calls. The
;; different patterns are only used to choose the right syntax.
;;
;; The svr4 m68k assembler recognizes this syntax: `bsr FUNC@PLTPC' and it
;; will create the correct relocation entry (R_68K_PLT32) for `FUNC',
;; that tells the linker editor to create an entry for `FUNC' in PLT
;; section at link time. However, all global objects reference are still
;; done by using `OBJ@GOT'. So, the goal here is to output the function
;; call operand as `FUNC@PLTPC', but output object operand as `OBJ@GOT'.
;; We need to have a way to differentiate these two different operands.
;;
;; The strategy I use here is to use SYMBOL_REF_FLAG to differentiate
;; these two different operands. The macro LEGITIMATE_PIC_OPERAND_P needs
;; to be changed to recognize function calls symbol_ref operand as a valid
;; PIC operand (by checking whether SYMBOL_REF_FLAG is set). This will
;; avoid the compiler to load this symbol_ref operand into a register.
;; Remember, the operand "foo@PLTPC" cannot be called via jsr directly
;; since the value is a PC relative offset, not a real address.
;;
;; All global objects are treated in the similar way as in SUN3. The only
;; difference is: on m68k svr4, the reference of such global object needs
;; to end with a suffix "@GOT" so the assembler and linker know to create
;; an entry for it in GOT (Global Offset Table) section. This is done in
;; m68k.c.
;; General case of fullword move.
;;
;; This is the main "hook" for PIC code. When generating
;; PIC, movsi is responsible for determining when the source address
;; needs PIC relocation and appropriately calling legitimize_pic_address
;; to perform the actual relocation.
;;
;; In both the PIC and non-PIC cases the patterns generated will
;; matched by the next define_insn.
;; This is the second "hook" for PIC code (in addition to movsi). See
;; comment of movsi for a description of PIC handling.
(define_expand "cmpsi"
/* Emit a (use pic_offset_table_rtx) if we used PIC relocation in the
function at any time during the compilation process. In the future
we should try and eliminate the USE if we can easily determine that
all PIC references were deleted from the current function. That would
save an address register */
void
finalize_pic ()
#ifdef MOTOROLA
asm_fprintf (stream, "\t%Olea (%Rpc, %U_GLOBAL_OFFSET_TABLE_@GOTPC), %s\n"
,
reg_names[PIC_OFFSET_TABLE_REGNUM]);
#else
asm_fprintf (stream, "\tmovel %0I__GLOBAL_OFFSET_TABLE_, %s\n",
reg_names[PIC_OFFSET_TABLE_REGNUM]);
asm_fprintf (stream, "\tlea %Rpc@(0,%s:l),%s\n",
reg_names[PIC_OFFSET_TABLE_REGNUM],
reg_names[PIC_OFFSET_TABLE_REGNUM]);
#endif
/* A C compound statement to output to stdio stream STREAM the
assembler syntax for an instruction operand that is a memory
reference whose address is ADDR. ADDR is an RTL expression.
Note that this contains a kludge that knows that the only reason
we have an address (plus (label_ref...) (reg...)) when not generating
PIC code is in the insn before a tablejump, and we know that m68k.md
generates a label LInnn: on such an insn.
It is possible for PIC to generate a (plus (label_ref...) (reg...))
and we handle that just like we would a (plus (symbol_ref...) (reg...)).
Some SGS assemblers have a bug such that "Lnnn-LInnn-2.b(pc,d0.l*2)"
fails to assemble. Luckily "Lnnn(pc,d0.l*2)" produces the results
we want. This difference can be accommodated by using an assembler
define such "LDnnn" to be either "Lnnn-LInnn-2.b", "Lnnn", or any other
string, as necessary. This is accomplished via the ASM_OUTPUT_CASE_END
macro. See m68k/sgs.h for an example; for versions without the bug.
Some assemblers refuse all the above solutions. The workaround is to
emit "K(pc,d0.l*2)" with K being a small constant known to give the
right behaviour.
They also do not like things like "pea 1.w", so we simple leave off
the .w on small constants.
This routine is responsible for distinguishing between -fpic and -fPIC
style relocations in an address. When generating -fpic code the
offset is output in word mode (eg movel a5@(_foo:w), a0). When generating
-fPIC code the offset is output in long mode (eg movel a5@(_foo:l), a0) */
/* Legitimize PIC addresses. If the address is already
position-independent, we return ORIG. Newly generated
position-independent addresses go to REG. If we need more
than one register, we lose.
An address is legitimized by making an indirect reference
through the Global Offset Table with the name of the symbol
used as an offset.
The assembler and linker are responsible for placing the
address of the symbol in the GOT. The function prologue
is responsible for initializing a5 to the starting address
of the GOT.
The assembler is also responsible for translating a symbol name
into a constant displacement from the start of the GOT.
A quick example may make things a little clearer:
When not generating PIC code to store the value 12345 into _foo
we would generate the following code:
movel #12345, _foo
When generating PIC two transformations are made. First, the compiler
loads the address of foo into a register. So the first transformation makes:
lea _foo, a0
movel #12345, a0@
The code in movsi will intercept the lea instruction and call this
routine which will transform the instructions into:
movel a5@(_foo:w), a0
movel #12345, a0@
That (in a nutshell) is how *all* symbol and label references are
handled. */
Il est possible de gerer soit meme le Position Independent Code.
Pour cela il faut mettre avant l'assembleur un traitement des @GOT en exces et
creer la Global Offset Table.
Il faut aussi faire des crt0 adaptes ainsi que les bouts de librairies en assembleur et l'ajout du symbole __GLOBAL_OFFSET_TABLE_.
Il serait interessant de faire des librairies trigonometriques adaptes au cpu32.
glibc : --nfp needed, probleme avec ENOMSG (errno.h) modif de errno.h a la racine ajout de la valeur de ENOMSG i.e 35,
Pour generer du code ROMable, il faut utiliser le format binary ieee : le seul a
supporter les sauts de .data au meme point que le .text.