This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: some questions of gcc-4.1.0/glibc-2.4 toolchain


--- Bridge Wu <mingqiao.wu@gmail.com> wrote:

> On 4/29/06, Steven Newbury <s_j_newbury@yahoo.co.uk> wrote:
> >
> > --- Bridge Wu <mingqiao.wu@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I got a toolchain with gcc-4.1.0/glibc-2.4/binutils-2.16.91.0.7 by
> > > using crossgcc. It has a litte difference with the old version. Here
> > > are some questions.
> > >
> > > 1. How to support multiple abi?
> > > It can compile application with -mabi=aapcs. This can be observed with
> > > "arm-iwmmxt-linux-gnueabi-objdum -p a.out | grep private", the result
> > > is
> > >               private flags = 4000002: [Version4 EABI] [has entry point]
> > >
> > > I suppose the toolchain should support old abi and the default is
> > > eabi. The test case shows the result with and without -mabi=aapcs is
> > > the same. But I cannot get an old abi object file. I cannot use
> > > -mabi=apcs option. I can use -mapcs, but the result is the same as
> > > -mabi=aapcs. How should I support multiple abi to the
> > > gcc-4.1.0/glibc-2.4 toolchain.
> > >
> > Are you using my patch for arm-iwmmxt-linux-gnueabi?  I defaults to
> mcpu=iwmmxt
> > and mabi=aapcs-linux.
> >
> > Be aware that you need an aapcs compatible ABI for iWMMXt mode.  You will
> have
> > to make sure that your -march is set to something appropriate.
> >
> I did not apply your patch. I searched here and found you have sent
> two iwmmxt patches. It's the second one, right?
Yes, the second one.  It may not apply cleanly to 4.1.0, it's actually diff'd
from 4.1.1, it should be easy to fix up though.

> 
> > > 2. Which floating point is used?
> > > I ever used objdump to see private flags in binary file show the
> > > floating point format. But from item 1 we cannot know it. I checked
> > > the binutils source file, seems FPA used, but I'm not sure.
> > >
> > Again my patch uses VFP since the iWMMXt does it in hardware.  If you you
> want
> > to be backward compatible with OABI you'll have to use FPA and/or softfloat
> > since it was a part of the ABI.  You'll need to use multilib I believe.
> >
> > > 3. How to modify gcc specs?
> > > I remembered there is a specs file which can control some behaviours
> > > of gcc. But following output shows the new toolchain uses built-in
> > > specs. Can I still modify gcc specs?
> > > $ arm-iwmmxt-linux-gnueabi-gcc -v
> > > Using built-in specs.
> > > Target: arm-iwmmxt-linux-gnueabi
> > > Configured with:
> > >
> >
>
/home/test/gcc41-glibc24-binu216/build/arm-iwmmxt-linux-gnueabi/gcc-4.1.0-glibc-2.4/gcc-4.1.0/configure
> > > --target=arm-iwmmxt-linux-gnueabi --host=i686-host_pc-linux-gnu
> > > --prefix=/usr/local/bridge/arm-iwmmxt-linux-gnueabi --with-cpu=iwmmxt
> > > --with-float=soft --enable-cxx-flags=-msoft-float
> > >
> >
>
--with-headers=/usr/local/bridge/arm-iwmmxt-linux-gnueabi/arm-iwmmxt-linux-gnueabi/include
> > >
> >
>
--with-local-prefix=/usr/local/bridge/arm-iwmmxt-linux-gnueabi/arm-iwmmxt-linux-gnueabi
> > > --disable-nls --enable-threads=posix --enable-symvers=gnu
> > > --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared
> > > --enable-c99 --enable-long-long
> > > Thread model: posix
> > > gcc version 4.1.0
> > Ah, you've used softfloat.  That may won't use FPA or VFP unless you
> specifiy
> > -mfloat-hard.
> A little confused. I remember -mhard-float is used to indicate hard
> FPU, -msoft-float indicate soft FPA and none indicate soft VFP
> according to gcc/config/arm/xscale-elf.h. But why gcc-4.1.0 does not
> use gcc/config/arm/xscale-elf.h and t-xscale-elf any more? I tried
> these options to compile c code and objdump always show the same
> result (i.e.private flags = 4000002: [Version4 EABI] [has entry
> point]).
As I understand the difference between soft FPA and soft VFP is down to which
standard is implemented in the softfloat lib.  I really doesn't matter much
unless you expect certain behaviour in you application.

The lack of inclusion of xscale-elf.h and t-xscale-elf are what motivated me to
make my patch.  The reason I made new configs and didn't just include those is
both to keep compatiblity for the "obsolete" xscale-* targets and because the
existing configs were not really suitable for Linux/EABI. The xscale-* targets
are for a stand-alone toolchain.
> 
> The files added in your patch are used as the spec, right? How are they used?
It just configures gcc to produce objects for the specified default.  Otherwise
"generic" ARM is targeted with the default specs.  The standard
arm-none-linux-gnueabi tool chain will produce code for iWMMXt if you tell it
to, but it's not the default.
> 
> >
> > Yes, you should be able to use your own specs in theory! :) Just make sure
> the
> > underlying support has been compiled in for any changes!
> I know not much about the specs. Would you like to give more detail?
> How to use our own specs? How to compile underlying support?
I just mean that you need to have available to you any options you specifify in
your spec.  If you don't have a softfloat lib available it won't work to put
softfloat in the specs for example.
> 
> >
> > I've only been digging deeply into this stuff for a couple of months so
> > although I don't think I've done anything wrong in my patch; at least
> nobody
> > has said anything!  It does seem to work! :)
As I said I'm not really an expert (yet!)..


Steve


	
	
		
___________________________________________________________ 
Win tickets to the 2006 FIFA World Cup Germany with Yahoo! Messenger. http://advision.webevents.yahoo.com/fifaworldcup_uk/

--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]