gcc binary format output

gcc binary format output

[Victor Roman Archidona]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Hi all,

I'm porting FreeBSD to Gentoo for the Summer of Code project
"Gentoo/FreeBSD for Amd64", and I need a little help about gcc binary
output when compiling files.

I compiled by hand GCC, and when I compile some file the output format
is "UNIX - System V". I got this with `readelf -h program`. The
problem is that I need the default binary output must be "UNIX -
FreeBSD" and for now I can't fix it without help.

BTW, If the output is "UNIX - System V" I can't run static compiled
files, it shall be fixed changing the output behaviour. For example
with the following small C program:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
        printf("it works!\n");
        exit(EXIT_SUCCESS);
}

root@localhost ~ # gcc -static test.c -o test
root@localhost ~ # readelf -h test | grep "OS/ABI"
  OS/ABI:                            UNIX - System V
root@localhost ~ # ./test
ELF binary type "0" not known.
- -su: ./test: cannot execute binary file
root@localhost ~ #

Any input in this topic will be very apreciated.

Thanks for all in advance,
- --
Victor Roman Archidona



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
 
iD8DBQFEtFAPQ/ddYKMfqaARAt8ZAJ91m1qOK0ssqwkR73DGBrDnKG2wvQCff45s
nCeS6o2yvI4LF6s0O/6Bb7U=
=ELEo
-----END PGP SIGNATURE-----

Re: gcc binary format output

[Ian Lance Taylor]

Victor Roman Archidona <daijo@unixevil.info> writes:

> I compiled by hand GCC, and when I compile some file the output format
> is "UNIX - System V".

When you compiled GCC yourself, what target did you use?

To get FreeBSD labelled binaries, you should configure with something
like
    --target=i386-freebsd

You will also need to build the binutils with that --target option.

Ian

Re: gcc binary format output

[Victor Roman Archidona]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Hi,

> Ian Lance Taylor escribió: When you compiled GCC yourself, what
> target did you use?

I didn't specified any target, my configure line was:

./configure --prefix=/usr
- --bindir=/usr/x86_64-gentoo-freebsd6.1/gcc-bin/3.4.6
- --includedir=/usr/lib/gcc/x86_64-gentoo-freebsd6.1/3.4.6/include
- --datadir=/usr/share/gcc-data/x86_64-gentoo-freebsd6.1/3.4.6
- --mandir=/usr/share/gcc-data/x86_64-gentoo-freebsd6.1/3.4.6/man
- --infodir=/usr/share/gcc-data/x86_64-gentoo-freebsd6.1/3.4.6/info
-
--with-gxx-include-dir=/usr/lib/gcc/x86_64-gentoo-freebsd6.1/3.4.6/include/g++-v3
- --host=x86_64-gentoo-freebsd6.1 --build=x86_64-gentoo-freebsd6.1
- --disable-altivec --disable-nls --with-system-zlib --disable-checking
- --disable-werror --disable-libunwind-exceptions --enable-multilib
- --disable-libgcj --enable-languages=c,c++ --enable-shared
- --enable-threads=posix --enable-__cxa_atexit

> To get FreeBSD labelled binaries, you should configure with
> something like --target=i386-freebsd

I used it with the error: "Please update *-*-freebsd* in
gcc/config.gcc" so I don't touch it (the $target that I got with that
was "i386-pc-freebsd"). Shall config.gcc sets the correct target?
Reading it I saw the case "*-*-freebsd[6].*)" and my CHOST is
"x86_64-gentoo-freebsd6.1" so it triggered the target with same results.

> You will also need to build the binutils with that --target option.
>
My binutils has the following BFDs: elf64-x86-64 elf32-i386-freebsd
coff-i386 efi-app-ia32, and emulations: elf_x86_64_fbsd elf_i386_fbsd
elf_x86_64 elf_i386

Thanks in advance,
- --
Victor Roman Archidona

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
 
iD8DBQFEtIoJQ/ddYKMfqaARAj3UAKCVYKDjOEaIWyPPKHuAsabpPpIbcACfYLMU
ToRvWAldWTCvTkxgU/iSCs8=
=dfcM
-----END PGP SIGNATURE-----

Re: gcc binary format output

[Ian Lance Taylor]

Victor Roman Archidona <daijo@unixevil.info> writes:

> > You will also need to build the binutils with that --target option.
> >
> My binutils has the following BFDs: elf64-x86-64 elf32-i386-freebsd
> coff-i386 efi-app-ia32, and emulations: elf_x86_64_fbsd elf_i386_fbsd
> elf_x86_64 elf_i386

In that case, I don't know.  Sorry.  A FreeBSD developer might be able
to help, or somebody else on this list.

Ian

register usage

[Petar Bajic]

I want to forbid compiler to use condition register for destination in movz 
instruction
instruction (if r3 == 0, move r2 to r1) should look like this:
movz r1, r2, r3  (r3 condition, r2 source, r1 destination register)
but compiler generates this
movz r3, r2, r3
and uses r3 further on. Wich is techincally ok, but I have this problem with 
overwritting condition and would like to save it.
How do I tell compiler to generate different register for destination?

Petar 

Re: register usage

[Andrew Haley]

Petar Bajic writes:
 > I want to forbid compiler to use condition register for destination in movz 
 > instruction
 > instruction (if r3 == 0, move r2 to r1) should look like this:
 > movz r1, r2, r3  (r3 condition, r2 source, r1 destination register)
 > but compiler generates this
 > movz r3, r2, r3
 > and uses r3 further on. Wich is techincally ok, but I have this problem with 
 > overwritting condition and would like to save it.
 > How do I tell compiler to generate different register for destination?

Put the condition code register in a different class from the other
registers.  

Andrew.

Re: register usage

[Petar Bajic]

----- Original Message ----- 
From: "Andrew Haley" <aph@redhat.com>
To: "Petar Bajic" <petar.bajic@micronasnit.com>
Cc: <gcc-help@gcc.gnu.org>
Sent: Wednesday, July 12, 2006 2:48 PM
Subject: Re: register usage


> Petar Bajic writes:
> > I want to forbid compiler to use condition register for destination in 
> > movz
> > instruction
> > instruction (if r3 == 0, move r2 to r1) should look like this:
> > movz r1, r2, r3  (r3 condition, r2 source, r1 destination register)
> > but compiler generates this
> > movz r3, r2, r3
> > and uses r3 further on. Wich is techincally ok, but I have this problem 
> > with
> > overwritting condition and would like to save it.
> > How do I tell compiler to generate different register for destination?
>
> Put the condition code register in a different class from the other
> registers.
>
> Andrew.
>

For this, I had to make two new register classes (machine has 32 regs and 
basicly just one reg class GENERAL_REGS)
I added two new classes: HI_REGS, and LO_REGS to "enum reg_classes" wich are 
lower and higher 16 regs of GENERAL_REGS.
REG_CLASS_CONTENTS is expanded with { 0xffff0000 } and { 0x0000ffff }
REG_CLASS_NAMES has two more names "HI_REGS" and "LO_REGS"

in machine.c file I modified  "reg_class_from_letter"  making letter 'j' and 
'k' return HI_REGS and LO_REGS

in machine.md I finally wrote a rule that uses j and k regs to distinct 
input and output....
(define_insn "*movsicc_insn"
  [(set (match_operand:SI 0 "register_operand" "=j,j")
 (if_then_else:SI (match_operator 1 "comparison_operator" [(match_operand:SI 
4 "register_operand" "=k,k") (const_int 0)])
    (match_operand:SI 2 "register_operand" "=d,d")
    (match_operand:SI 3 "register_operand" "=d,d")))]
  ""
"..."

and the error is:
../../gcc/libgcc2.c:785: internal compiler error: in copy_to_mode_reg, at 
explow.c:581

what else do I have to do for this to work?

Re: register usage

[Andrew Haley]

Petar Bajic writes:
 > 
 > 
 > For this, I had to make two new register classes (machine has 32 regs and 
 > basicly just one reg class GENERAL_REGS)
 > I added two new classes: HI_REGS, and LO_REGS to "enum reg_classes" wich are 
 > lower and higher 16 regs of GENERAL_REGS.
 > REG_CLASS_CONTENTS is expanded with { 0xffff0000 } and { 0x0000ffff }
 > REG_CLASS_NAMES has two more names "HI_REGS" and "LO_REGS"
 > 
 > in machine.c file I modified  "reg_class_from_letter"  making letter 'j' and 
 > 'k' return HI_REGS and LO_REGS
 > 
 > in machine.md I finally wrote a rule that uses j and k regs to distinct 
 > input and output....
 > (define_insn "*movsicc_insn"
 >   [(set (match_operand:SI 0 "register_operand" "=j,j")
 >  (if_then_else:SI (match_operator 1 "comparison_operator" [(match_operand:SI 
 > 4 "register_operand" "=k,k") (const_int 0)])
 >     (match_operand:SI 2 "register_operand" "=d,d")
 >     (match_operand:SI 3 "register_operand" "=d,d")))]
 >   ""
 > "..."
 > 
 > and the error is:
 > ../../gcc/libgcc2.c:785: internal compiler error: in copy_to_mode_reg, at 
 > explow.c:581
 > 
 > what else do I have to do for this to work?

I would look in the debugger to see what copy_to_mode_reg was trying
to do.  

I suspect you haven't defined a pattern to move into one of the
register classes.

Andrew.

Re: gcc binary format output

[Kai Ruottu]

Victor Roman Archidona wrote:

 > I compiled by hand GCC, and when I compile some file the output format
 > is "UNIX - System V". I got this with `readelf -h program`.
 > root@localhost ~ # gcc -static test.c -o test
 > root@localhost ~ # readelf -h test | grep "OS/ABI"
 > OS/ABI: UNIX - System V

I tried a crosscompiler from 'i686-linux-gnu' to the 'x86_64-freebsd6.1'
and got just the same result:

kai@Dell:/data1/home/kai-old/test/tprintf> readelf -h tst_freebsd64.x | 
grep OS/ABI
  OS/ABI:                            UNIX - System V

while the binaries in the FreeBSD6.1/amd64 install CD like it's 'gcc' 
and 'libc.so.6' had:

kai@Dell:/media/cdrecorder/usr/bin> readelf -h gcc | grep OS/ABI
  OS/ABI:                            UNIX - FreeBSD
kai@Dell:/media/cdrecorder/lib> readelf -h libc.so.6 | grep OS/ABI
  OS/ABI:                            UNIX - FreeBSD

So the executables produced have this wrong type...  I would guess GCC 
or the GNU 'as'
should be sued for this thing because:

kai@Dell:/data1/home/kai-old/test/tprintf> readelf -h tst_freebsd64.o | 
grep OS/ABI
  OS/ABI:                            UNIX - System V

The binutils I used were the latest '2.17.50.0.2' Linux ones from:

   ftp.kernel.org/pub/linux/devel/binutils

The GCC version tried was '4.0.3'...  I will try gcc-4.1.1 still but 
getting this bug fixed also
in gcc-4.0.x could be nice.  Anyone knowing this much about binutils and 
GCC, which config
etc. setting could cause the 'bad magic'?  The right FreeBSD bins have:

Magic:   7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00

but the wrong ones have:

Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00

Re: gcc binary format output

[Andrew Haley]

Kai Ruottu writes:
 > Victor Roman Archidona wrote:
 > 
 >  > I compiled by hand GCC, and when I compile some file the output format
 >  > is "UNIX - System V". I got this with `readelf -h program`.
 >  > root@localhost ~ # gcc -static test.c -o test
 >  > root@localhost ~ # readelf -h test | grep "OS/ABI"
 >  > OS/ABI: UNIX - System V
 > 
 > I tried a crosscompiler from 'i686-linux-gnu' to the 'x86_64-freebsd6.1'
 > and got just the same result:

This is way off-topic.  gcc produces assembly code, not binaries.  You
should be talking to a binutils list.

Andrew.

Re: gcc binary format output

[Kai Ruottu]

Andrew Haley wrotes:
> Kai Ruottu writes:
>  > Victor Roman Archidona wrote:
>  > 
>  >  > I compiled by hand GCC, and when I compile some file the output format
>  >  > is "UNIX - System V". I got this with `readelf -h program`.
>  > 
>  > I tried a crosscompiler from 'i686-linux-gnu' to the 'x86_64-freebsd6.1'
>  > and got just the same result:
>
> This is way off-topic.  gcc produces assembly code, not binaries.  You
> should be talking to a binutils list.
>   
I myself haven't joined to the binutils list, only to this and the gcc list.
And generally did my try 'just for a fun' in this specific case,  but
Victor Roman Archidona could have some motives to get this thing
working in his own project...  Anyhow the fix being told after it was
invented could be nice.  At least to me if my message gave any clues
for where the bug could be :-)  Otherwise I will stop all the further
build tries and maybe can give misinformation about the binutils/GCC
situation with FreeBSD/x86_64 when not being informed that the bug
was fixed already...

 BTW, for those who (still) don't know "how to build a crosscompiler" (like
those who write the GNU docs :-) here is my usual method :

 For my crosscompiler to 'x86_64-freebsd6.1', I first built and 
installed the
binutils-2.17.50.0.2 for this target. Then I installed the target C 
library from
the FreeBSD 6.1/amd64 install CDs and finally built gcc-4.0.3 from its 
sources.
This is the method I have used to, and there should be some very good 
reasons
to get me learning how on earth the C libraries for FreeBSD could be built
from absolute scratch...

 The only problem during the build, for which I should have asked comments
here but forgot to do that, was that the target headers, specifically the
'<machine/_types.h>', already defined the '__gnuc_va_list' but the
'gcc-4.0.3/gcc/sys-types.h' tried to define this again.  My 
quick-and-dirty fix
was to wrap the 'gcc-4.0.3/gcc/sys-types.h' with the same:

    #ifndef __GNUC_VA_LIST
    #define __GNUC_VA_LIST
    <the '__gnuc_va_list' typedef>
    #endif

wrapper as this FreeBSD 6.1 header had.  Maybe the right fix could have been
to redefine this (gcc-4.0.3-wise) in the 'gcc/sys-types.h'.  This clash 
happened
when the new 'xgcc' & Co. tried to compile the '$build/gcc/SYSCALLS.c'...

 In any case my build method had not much to do with the current GNU site
'advices', I just did the build in the same way I have done a GCC build 
during
the last 10 years and during the last 1000  builds....

 I can quite well agree with Andrew about binutils and C library things 
not belonging
to GCC in any way, but how on earth this fact could be told to the GNU docs
writers?   The 'http://gcc.gnu.org/install/prerequisites.html' doesn't 
mention
anything about the C library and (almost) claims the binutils being 
something
'optional'.  For the crosscompiler builders both these are obligatory 
prerequisites
and in most cases the target C library already exists in the target 
system itself.

 The: 'http://gcc.gnu.org/install/build.html' tells instead :

   Build runtime libraries using the stage3 compiler from the previous step.

for the native case and:

    * Build the compiler (single stage only).
    * Build runtime libraries using the compiler from the previous step.

for the cross case.  But whether a newbie understands what these 
'runtime libraries'
are, is quite unclear.  After producing those 1000 and much more GCCs, 
neither
do I understand what these mean.  Should the native GCC builder try to 
build the
C libraries after the GCC build or what?  And the crosscompiler builder 
should do
the same?  In the embedded target cases this really happens, people like 
me usually
produce the C library (newlib) after getting GCC ('gcc', 'libiberty', 
'libstdc++',...)
built.   The "single stage only" is some sanity but as we have seen 
recently on this
list :

------------------ clip --------------------------
Raphael Zulliger wrote:

 > Building a crosscompiler should be done as described in the different 
docs/wikis/howtos.
------------------ clip --------------------------

all kind of  "how-to"s  and "wiki"s try to use the famous "code red" for 
the new 'recruits':

  http://en.wikipedia.org/wiki/A_Few_Good_Men

in their first crosscompiler builds, "a form of hazing unofficially 
sanctioned by
higher-ranking officers designed to make soldiers pay attention to 
orders and rules".
To their own "orders and rules", not to the GNU rules like this "single 
stage only" :-(

 As an corporal (now in reserves) in the Finnish recruit army, Signal 
Corps, I didn't like
using that 'code red' into those recruits.  And don't understand why 
anyone likes using
it nowadays for the newbies in GCC building, with their self-invented 
multi-stage builds
others "should use" (like Raphael writes).  Not funny at all but really 
sad...

Re: gcc binary format output

[Victor Roman Archidona]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
> Kai Ruottu escribió: for where the bug could be :-)  Otherwise I
> will stop all the further build tries and maybe can give
> misinformation about the binutils/GCC situation with FreeBSD/x86_64
> when not being informed that the bug was fixed already...
Thanks for your feedback Kai. In the binutils mailing list has been
sent a patch that fixes the problem. The URL for anyone interested in
it is:

http://www.sourceware.org/ml/binutils/2006-07/msg00192.html

An example of binutils-2.17 with patch applied:

root@localhost ~ # gcc -static test.c -o test
root@localhost ~ # ./test
it works!
root@localhost ~ # file test
test: ELF 64-bit LSB executable, AMD x86-64, version 1 (FreeBSD), for
FreeBSD 6.1, statically linked, for FreeBSD 6.1, not stripped
root@localhost ~ #


Regards,
- --
Victor Roman Archidona

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
 
iD8DBQFEuPUoQ/ddYKMfqaARAuOvAKCFyN7MtdW/ZdnpGMTeecLb4B1XCwCgj0iV
MyMxa/7cTWZVLTpAnlD5yJY=
=9Rru
-----END PGP SIGNATURE-----

Re: gcc binary format output

[Kai Ruottu]

Victor Roman Archidona kirjoitti:
> Thanks for your feedback Kai. In the binutils mailing list has been
> sent a patch that fixes the problem. The URL for anyone interested in
> it is:
>
> http://www.sourceware.org/ml/binutils/2006-07/msg00192.html
>   
Thanks to you too!

 I tried also a crosscompiler for the 32-bit FreeBSD 6.1/i386
and checked if the 'bfd/config.bfd' had anything special for
this target, different from the Linux/i386 for instance. And
it definitely had, and this special 'bfd_elf32_i386_freebsd_vec'
not listed for  the  'x86_64-*-freebsd*'...  Adding that maybe
fixed the 32-bit support with '-m32' but not the 64-bit.  So
I already guessed that something should still be done to implement
that missing 'bfd_elf64_x86_64_freebsd_vec'.  The 'alpha' port
for FreeBSD had its own special 'elf64_alpha_freebsd_vec'
already...

 Why the official GNU binutils don't have this support for the
FreeBSD/x86_64 (I checked the '060713' snapshots too), was
of course weird. Anyway getting it "locally" should now
succeed...
> An example of binutils-2.17 with patch applied:
>
> root@localhost ~ # gcc -static test.c -o test
> root@localhost ~ # ./test
> it works!
> root@localhost ~ # file test
> test: ELF 64-bit LSB executable, AMD x86-64, version 1 (FreeBSD), for
> FreeBSD 6.1, statically linked, for FreeBSD 6.1, not stripped
> root@localhost ~ #
>   
 The 'i586-freebsd6.1' target toolchains (gcc-3.4.6, 4.0.3 and
4.1.1) I built seemed to produce quite "right" executables,
lets see what the 'x86_64-freebsd6.1' ones will do now.  Of
course reproducing all their 'libgcc_s.so.1's and 'libstdc++.so's
must be done...

Re: gcc binary format output

[Kai Ruottu]

Kai Ruottu kirjoitti:
> Victor Roman Archidona kirjoitti:
>> Thanks for your feedback Kai. In the binutils mailing list has been
>> sent a patch that fixes the problem. The URL for anyone interested in
>> it is:
>>
>> http://www.sourceware.org/ml/binutils/2006-07/msg00192.html
>>   
> lets see what the 'x86_64-freebsd6.1' ones will do now.
The given patches weren't enough :-(   The resulted GNU linker complained
about not finding the output format etc.  A quick "how these things were 
done
in 'alpha', 'i386' etc." comparison revealed that also the 'ld/emulparams'
directory required the following patch in the current 
'binutils-2.17.50.0.3' :

---------------- clip ----------------------------
*** elf_x86_64_fbsd.sh.orig     Thu Mar  7 21:52:39 2002
--- elf_x86_64_fbsd.sh  Tue Jul 18 15:06:58 2006
***************
*** 1,2 ****
--- 1,3 ----
  . ${srcdir}/emulparams/elf_x86_64.sh
  . ${srcdir}/emulparams/elf_fbsd.sh
+ OUTPUT_FORMAT="elf64-x86-64-freebsd"
---------------- clip ----------------------------


After adding this the produced binutils gave right labeled executables and
more importantly the crosscompilers to the 'x86_64-freebsd6.1' target
could be built, giving seemingly OK shared libraries with the following:

kai@Dell:/data1/home/src/gcc-4.0.3/build/gcc> readelf -h libgcc_s.so.1
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - FreeBSD
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1


output got via the 'readelf -h'...

Re: gcc binary format output

[Victor Roman Archidona]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 

> The given patches weren't enough :-(   The resulted GNU linker
> complained about not finding the output format etc.  A quick "how
> these things were done in 'alpha', 'i386' etc." comparison revealed
> that also the 'ld/emulparams' directory required the following
> patch in the current 'binutils-2.17.50.0.3' :
>
I sent that yesterday to binutils mailing list, the message with the
modified patch is the following:

http://sources.redhat.com/ml/binutils/2006-07/msg00220.html

Regards,
- --
Victor Roman Archidona
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
 
iD8DBQFEvOwdQ/ddYKMfqaARAgO9AKCD8fUwNh0AK5ZlVs2+9QMpJ3q1yQCfc1Va
W3G7meCtqES2NUtTJu+lFtk=
=il1C
-----END PGP SIGNATURE-----

Re: gcc binary format output

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

On Tuesday 18 July 2006 08:37, Kai Ruottu wrote:
> The given patches weren't enough :-(   The resulted GNU linker complained
> about not finding the output format etc.  A quick "how these things were
> done
> in 'alpha', 'i386' etc." comparison revealed that also the 'ld/emulparams'
> directory required the following patch in the current
> 'binutils-2.17.50.0.3' :

Victor already posted this fix ... best if you follow the new thread on the 
binutils list rather than continuing this cross-posted one
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: Register Usage

[Richard Earnshaw]

On Wed, 2009-04-29 at 05:14 -0700, John Farmer wrote:
> Hi Richard,
> 
> Applogies if this sounds silly but I am new to the GCC toolchain.
> 
> Are you saying that arm-none-eab is a type of compiler and not a command
> line option? 

Yes, when you build GCC from the sources you get to determine both what
machine you want to target (ARM, MIPS, Sparc, etc) and what sort of
platform will be running on your machine (Linux, Solaris, bare-metal (ie
no OS).  You can find out what configuration was used for your
particular compiler if you invoke GCC with just the -v option.  For
example, a compiler I have here says:

[RWE]$ arm-eabi-gcc -v
Target: arm-eabi
Configured with: /home/rearnsha/gnusrc/gcc-cross/trunk/configure
--prefix=/work/rearnsha/gnu/trunk/testinstall --enable-checking=release
--disable-werror --enable-languages=c,c++ --target=arm-eabi
--with-headers=/home/rearnsha/gnusrc/gcc-cross/trunk/newlib/libc/include
--with-newlib --disable-libmudflap
--with-gmp=/home/rearnsha/gnu/install/x86
Thread model: single
gcc version 4.4.0 20081112 (experimental) (GCC) 

> 
> The GCC tools "as" and "cc1" that I have are part of the development IDE
> (CrossWorks for ARM) that I am using and are based on GCC V4.1.1. 
> 

If your target isn't for the EABI (see above), then I think you'll need
to talk to the CrossWorks people to find out how to get one.

> Would I be correct in thinking that "as" and "cc1" would have been built
> specifically for the ARM CPU? Looking at the --help for these the only CPU
> options shown are for the ARM which presumably suggests that many (non-ARM)
> options have been removed.

Indeed (see above).

R.

Re: Register Usage

[John Farmer]

Hi Richard,

Applogies if this sounds silly but I am new to the GCC toolchain.

Are you saying that arm-none-eab is a type of compiler and not a command
line option? 

The GCC tools "as" and "cc1" that I have are part of the development IDE
(CrossWorks for ARM) that I am using and are based on GCC V4.1.1. 

Would I be correct in thinking that "as" and "cc1" would have been built
specifically for the ARM CPU? Looking at the --help for these the only CPU
options shown are for the ARM which presumably suggests that many (non-ARM)
options have been removed.

Regards John
-- 
View this message in context: http://www.nabble.com/Register-Usage-tp23279910p23295829.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: Register Usage

[Richard Earnshaw]

On Wed, 2009-04-29 at 03:18 -0700, John Farmer wrote:
> Hi Richard,
> 
> I have downloaded the docs and am having a browse now, thanks.
> 
> I did export the projects build file and searched it for "abi" but only
> found "-mfloat-abi=soft" which specifies an ABI for floating point values.
> There is a GCC option "-mabi=name" but that does not appear anywhere in my
> command lines. Given that the -mabi option is not present presumably I am
> using a default ABI, but what is it?
> 

The short answer is that it depends on your compiler's configuration; if
you used arm-none-eabi (which is what I would recommend for bare-metal
use on a CPU like Cortex-m3), then it will be based on the new ABI.

> Is there a way to get GCC to display all of its default options that it uses
> when for example certain comman line options are not specified?

The only information that is printed comes out with --help (you'll get
more detailed help if you also specify a source file of the language you
want help for), or what you can find in the manual.

R.

Re: Register Usage

[John Farmer]

Hi Richard,

I have downloaded the docs and am having a browse now, thanks.

I did export the projects build file and searched it for "abi" but only
found "-mfloat-abi=soft" which specifies an ABI for floating point values.
There is a GCC option "-mabi=name" but that does not appear anywhere in my
command lines. Given that the -mabi option is not present presumably I am
using a default ABI, but what is it?

Is there a way to get GCC to display all of its default options that it uses
when for example certain comman line options are not specified?

Regards John
-- 
View this message in context: http://www.nabble.com/Register-Usage-tp23279910p23294443.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: Register Usage

[Richard Earnshaw]

On Tue, 2009-04-28 at 15:06 -0700, John Farmer wrote:
> Hi Ian thanks for the reply,
> 
> I had a good look through the ARM-THUMB Procedure Call Standard and it sort
> of suggests that R7 could be used as a frame pointer. Looked through the GCC
> docs and found the -fabi option but it appears to apply to C++ code.
> 

The ARM-THUMB Procedure Call standard was superseded by "The ABI for the
ARM Architecture" nearly 5 years ago now, you can obtain the most recent
documents from the ARM documentation website:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.set.swdev/index.html

The current PCS is supported in gcc by several configurations (most of
which have 'eabi' somewhere in the configuration name; for Cortex-m3 I
strongly recommend you use one of those configurations.  You might also
want to configure the compiler with "--with-isa=thumb" and
"--with-cpu=cortex-m3"; this will save you from having to modify your
configure scripts or compiler command lines every time you build some
code.

> I am still wondering what makes the decision to use R7 as the frame pointer.
> If its used because of an ABI standard for the ARM Cortex-M3 CPU how is it
> specified to GCC? Also if this is the case is there a standard that I could
> look through? I have looked on the ARM web site but not found it yet.

The procedure call standards do not specify a frame pointer any more
(and haven't for nearly 15 years -- ie since Thumb was added to the
architecture).  So any compiler using a frame pointer is free to use
whatever register is wishes to.  In thumb you want to avoid using a
frame pointer whenever possible since non-stack based addressing is
severely limited in the offsets that are permitted.

R.

Re: Register Usage

[John Farmer]

Hi Ian,

I do not want to change to another register for R7 just wondered how the
decission was made to use it in the first place. Was it because Thumb = R7
or because the GCC adheres to some specification that states it must use R7.
If there is such a specification where abouts could I find it?

Regards John
-- 
View this message in context: http://www.nabble.com/Register-Usage-tp23279910p23292398.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: Register Usage

[Ian Lance Taylor]

John Farmer <news02@lavabit.com> writes:

> I had a good look through the ARM-THUMB Procedure Call Standard and it sort
> of suggests that R7 could be used as a frame pointer. Looked through the GCC
> docs and found the -fabi option but it appears to apply to C++ code.
>
> I am still wondering what makes the decision to use R7 as the frame pointer.
> If its used because of an ABI standard for the ARM Cortex-M3 CPU how is it
> specified to GCC? Also if this is the case is there a standard that I could
> look through? I have looked on the ARM web site but not found it yet.

When gcc needs a frame pointer in Thumb code, it will always use r7.
There is no way to change this.  I'm not sure why you would want to
change it.

Ian

Re: Register Usage

[John Farmer]

Hi Ian thanks for the reply,

I had a good look through the ARM-THUMB Procedure Call Standard and it sort
of suggests that R7 could be used as a frame pointer. Looked through the GCC
docs and found the -fabi option but it appears to apply to C++ code.

I am still wondering what makes the decision to use R7 as the frame pointer.
If its used because of an ABI standard for the ARM Cortex-M3 CPU how is it
specified to GCC? Also if this is the case is there a standard that I could
look through? I have looked on the ARM web site but not found it yet.

Regards John

-- 
View this message in context: http://www.nabble.com/Register-Usage-tp23279910p23287035.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: Register Usage

[Ian Lance Taylor]

John Farmer <news02@lavabit.com> writes:

> Register R12 is initialised in my startup code to the same value as the SP
> (R13) but it never appears to be used for anything. Whats the purpose of
> this register?
>
> I have looked at the ARM and THUMB procedure call standard (briefly) and it
> looks as though R7 is the Thumb-state Work register or variable register.
> However, looking at the assembly code produced for functions it is clearly
> being used as the frame pointer. Why is there a difference?
>
> Is there a defining text somewhere that details GCC register usage when
> compiling for a Cortex-M3 chip?

gcc follows the various ARM ABIs, which are documented on arm.com.  I
don't know which particular ABI you are using--it depends upon how gcc
was configured.

r12 is known as ip.  gcc will use it as a temporary general purpose
register.  It is also used in the prologue to set up the stack frame; I
think this use may be mandated by the ABI, but I'm not sure.

r7 is used as the frame pointer in Thumb code because r12 is not
accessible for general use.

By the way, make sure you are looking at optimized code.

Ian

Register Usage

[John Farmer]

Hi,

I am trying to understand how the general purpose registers are used by the
GCC compiler. Most I have been able to work out but have these questions.

Register R12 is initialised in my startup code to the same value as the SP
(R13) but it never appears to be used for anything. Whats the purpose of
this register?

I have looked at the ARM and THUMB procedure call standard (briefly) and it
looks as though R7 is the Thumb-state Work register or variable register.
However, looking at the assembly code produced for functions it is clearly
being used as the frame pointer. Why is there a difference?

Is there a defining text somewhere that details GCC register usage when
compiling for a Cortex-M3 chip?

I am using GCC V4.1.1 and a STM32F103RB (Cortex-M3) microcontroller.

Regards


-- 
View this message in context: http://www.nabble.com/Register-Usage-tp23279910p23279910.html
Sent from the gcc - Help mailing list archive at Nabble.com.