This is the mail archive of the crossgcc@sources.redhat.com 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: newlib on powerpc-eabi with soft-float


Christopher Jenkins wrote:
> 
> I don't understand what you mean by this. Do you mean that the linker
> cannot see libgcc.a because I have no _start symbol? As I explained in my
> previous email, I found that copying the libgcc.a built on my windows
> machine to my AIX machine seems to fix this problem, so I suspect that
> libgcc.a could be being built incorrectly on my AIX machine.
>
> > powerpc-eabi-gcc -o test test.c -msoft-float -lc

 This should have a '-msim', '-myellowknife' or something to define the
"target board" (including the 'psim'). The 'eabi' isn't anything real (like
an opsys or a target board with defined firmware on it), so one cannot link
apps for it only. Something more will be needed as default.

 But you may have edited your 'specs' file to have rules for some default
target board and the given 'compile' command could succeed.  But in the
'plain vanilla' case, when using the FSF-sources 'as-is', one needs one of
the following options (taken from the GCC-manual, "Invoking/Submodel options
/RS6000 and PowerPC Options") :

-msim
	On embedded PowerPC systems, assume that the startup module is
	called sim-crt0.o and that the standard C libraries are libsim.a
	and libc.a.  This is the default for powerpc-*-eabisim.  configurations.

-mmvme
	On embedded PowerPC systems, assume that the startup module is
	called crt0.o and the standard C libraries are libmvme.a and libc.a.

-mads
	On embedded PowerPC systems, assume that the startup module is called
	crt0.o and the standard C libraries are libads.a and libc.a.

-myellowknife
	On embedded PowerPC systems, assume that the startup module is called
	crt0.o and the standard C libraries are libyk.a and libc.a.

and then gets the executable linker for some of the supported target boards.

 The C-startup and the '_start()' there is where the C-program starts and the
'glue library', 'libsim.a', 'libmvme.a', 'libads.a' or 'libyk.a' has the missing
HW-dependent functions for the PowerPC-target board.  If your board is none of
these, you should try to search for any support stuff for it... The Cygnus 'bsp'-
package has more support libraries and the current RedHat 'RedBoot' too...

 Or you must implement your own support routines.  The 'bsp' docs seem to use
just the 'ppc-eabi' in its example :

-------------------------- clip ---------------------------------------------
New Boards

Configuration

The first step to porting to a new board is to add that board to the
configuration. This is done in the bsp/configure.in file. For each
supported architecture, configure.in has a list of supported boards
for that architecture. Suppose you want to add board fooppc to the
list of boards for powerpc-eabi builds. Looking in configure.in, you
will see some code which looks like:

powerpc-*-eabi)
      archdir="ppc";
      boards="cma101 mbx evb403 yellowknife/yka yellowknife/ykb yellowknife/yklb";
      extra_subdirs="yellowknife";
      ;;

You will need to add fooppc to the boards variable. Anytime configure.in
is modified, the configure script must be regenerated using autoconf.
Now that the board fooppc is added to the configure script, configure
will try to find a makefile fragment named board.mk in the directory
bsp/ppc/fooppc.
-------------------------- clip ---------------------------------------------

 The 'cma101', 'mbx' and 'evb403' seem to be some additional PPC-boards
with their support outside newlib/libgloss...

>  The obvious 'bug' here wasn't yet mentioned... "The bigger mistake one
> does, the harder it is for others to see it..."
> > /usr/toolchain/powerpc-eabi/bin/ld: warning: cannot find entry symbol
> > _start; defaulting to 01800074

 The '_start' is defined in the startup, 'crt0.o'...

E:\usr\local\ppc-eabi\lib\nof>..\..\bin\nm crt0.o
00008000 ? .LCTOC1
00000000 G __atexit
         U __bss_start
         U __sbss_end
         U __sbss_start
         U __stack
         U _end
00000004 T _start	<------------ !
         U atexit
         U exit
         U main

> > /usr/toolchain/powerpc-eabi/lib/nof/libc.a(vfprintf.o): In function
> > `_vfprintf_r':
> > 1.10.0/newlib/libc/stdio/vfprintf.c:592:
> > undefined reference to `__ltdf2'

 And this symbol is in 'libgcc.a'...

>  Seemingly no startup (with '_start()'), no 'libgcc.a' etc. weren't linked
> against...

 That the startup wasn't linked at all may have caused some kind of chain-
reaction...  I don't think your words "copying the libgcc.a built on my windows
machine to my AIX machine seems to fix this problem" being true because normally
'libgcc.a' doesn't include the startup-routine, and so not the needed symbol,
'_start', unless someone added the startup object there... Perhaps the Windows-
hosted 'libgcc.a' is some special modified one, not the original coming from the
GCC-build...

 Using the 'powerpc-eabi-nm' for looking at the symbol names helps one to see if
some symbol is defined in a library or not. Piping the command to 'grep' gives a
quick answer, for instance:

  powerpc-eabi-nm libgcc.a | grep __muldf3

would tell whether the '__muldf3' is defined ('T') there, or undefined ('U') in
some functions...

 One possible reason for symbol names not being found:

 Years ago 'ranlib' was needed to add create 'index' to the archive with non-ELF
libraries (nowadays 'ar' should do this when adding objects) otherwise the symbols
weren't found... Maybe your 'libgcc.a' archive wasn't indexed with the used 'ar'
(the native 'ar') and running 'ranlib' for it would make it now usable...

 BTW, your original command :

   powerpc-eabi-gcc -o test test.c -msoft-float -lc

isn't one I have used to see or use, but a command like:

   powerpc-eabi-gcc -msoft-float -o test test.c -lc

would be... Putting the things in this order perhaps has no other explanation than
"everybody seems to use this order", however I don't expect the '-msoft-float'
being after the C-file name causing any problems, it is only in a 'weird' place
now... The template for the common order is the one commonly used in makefiles:

   $(CC) $(CFLAGS) -o ofile ifile.c $(LDFLAGS)

 The command :

   powerpc-eabi-gcc -v -msim -msoft-float -o test test.c

would produce an executable for the 'psim'-PowerPC-simulator, included with
GDB, and to use the soft-float routines on it, in the plain vanilla FSF-case.
And the familiar '-v' would show what happens while 'compiling'...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


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