Re: binutils 2.9 powerpc-rtems breakage

Re: binutils 2.9 powerpc-rtems breakage

[Ian Lance Taylor]

   Date: Tue, 14 Apr 1998 12:39:55 -0500 (CDT)
   From: Joel Sherrill <joel@OARcorp.com>

   Anyway, I put the gcc command line in a script and then monkeyed with the
   arguments.  It looks like -mlittle is enough by itself to break it.  It
   breaks with all the arguments, just -mlittle, but works will the args
   minus -mlittle.   See this output from my test script:

   ...

   The only things which vary are the arguments:

   In (1), -mlittle -mrelocatable-lib -mno-eabi
   In (2), -mlittle
   In (3), -mrelocatable-lib -mno-eabi

   (1) and (2) report the error.

   Any ideas on what to look at?

Well, first try to recreate it by invoking gas directly, without
getting involved with gcc.

Once you can do that, set a breakpoint on output_file_create in gas,
and see what format it is passing to bfd_openw, and see why that
format is not defined by BFD.

Ian

Re: binutils 2.9 powerpc-rtems breakage

[Joel Sherrill]

On Mon, 13 Apr 1998, Ian Lance Taylor wrote:

>    Date: Mon, 13 Apr 1998 16:21:53 -0500 (CDT)
>    From: Joel Sherrill <joel@OARcorp.com>
> 
>    I can produce a .s file using -s and then assemble that file with:
> 
>    ./as -mppc -V -Qy -mrelocatable-lib libgcc2.s
> 
>    which indicates to me that somehow the rtems configuration lost support
>    for the -mlittle option.  powerpc-rtems should be identical to
>    powerpc-eabi if that trips anyone's memory.
> 
> What happens if invoke as directly with -mlittle?
> 
> -mlittle still seems to work for me for the powerpc-eabi target.  I
> don't know what's happening with your build.

I have not attempted to build powerpc-eabi but I may need to do that.
Something is also failing with mips64orion-rtems that I need to look into.

Anyway, I put the gcc command line in a script and then monkeyed with the
arguments.  It looks like -mlittle is enough by itself to break it.  It
breaks with all the arguments, just -mlittle, but works will the args
minus -mlittle.   See this output from my test script:

+ /usr1/rtems/work/tools/build-powerpc-tools/gcc/xgcc
-B/usr1/rtems/work/tools/build-powerpc-tools/gcc/ -O2 -DCROSS_COMPILE
-DIN_GCC -O2 -I./include -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-fexceptions -Dinhibit_libc -mlittle -mrelocatable-lib -mno-eabi
-mstrict-align -I. -I../../src/gcc -I../../src/gcc/config -DL_muldi3
../../src/gcc/libgcc2.c -c
Assembler messages:
FATAL: Can't create libgcc2.o: Invalid bfd target

+ /usr1/rtems/work/tools/build-powerpc-tools/gcc/xgcc
-B/usr1/rtems/work/tools/build-powerpc-tools/gcc/ -O2 -DCROSS_COMPILE
-DIN_GCC -O2 -I./include -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-fexceptions -Dinhibit_libc -mlittle -mstrict-align -I. -I../../src/gcc
-I../../src/gcc/config -DL_muldi3 ../../src/gcc/libgcc2.c -c
Assembler messages:
FATAL: Can't create libgcc2.o: Invalid bfd target

+ /usr1/rtems/work/tools/build-powerpc-tools/gcc/xgcc
-B/usr1/rtems/work/tools/build-powerpc-tools/gcc/ -O2 -DCROSS_COMPILE
-DIN_GCC -O2 -I./include -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-fexceptions -Dinhibit_libc -mrelocatable-lib -mno-eabi -mstrict-align -I.
-I../../src/gcc -I../../src/gcc/config -DL_muldi3 ../../src/gcc/libgcc2.c
-c

The only things which vary are the arguments:

In (1), -mlittle -mrelocatable-lib -mno-eabi
In (2), -mlittle
In (3), -mrelocatable-lib -mno-eabi

(1) and (2) report the error.

Any ideas on what to look at?

--joel

Re: binutils 2.9 powerpc-rtems breakage

[Joel Sherrill]

On Tue, 14 Apr 1998, Ian Lance Taylor wrote:

> Once you can do that, set a breakpoint on output_file_create in gas,
> and see what format it is passing to bfd_openw, and see why that
> format is not defined by BFD.

Done.  Here is the gdb session.  It looks like even though I configure
with --enable-targets=all, I am missing elf32-powerpcle support.

(gdb) b output_file_create
Breakpoint 2 at 0x8053483: file ../../src/gas/output-file.c, line 46.
(gdb) run -mlittle
Starting program: /usr1/rtems/work/tools/build-powerpc-tools/gcc/as
-mlittle
During symbol reading...inner block not inside outer block...
block at 0x4000e041 out of order...
Breakpoint 1 at 0x4002a0c6: file ../sysdeps/generic/abort.c, line 134.

During symbol reading...inner block not inside outer block...
inner block not inside outer block...

Breakpoint 2, output_file_create (name=0x8155a45 "a.out")
    at ../../src/gas/output-file.c:46
46        if (name[0] == '-' && name[1] == '\0')
(gdb) bt
#0  output_file_create (name=0x8155a45 "a.out")
    at ../../src/gas/output-file.c:46
#1  0x804b6ed in main (argc=1, argv=0x81a8818) at ../../src/gas/as.c:752
(gdb) n
50        else if (!(stdoutput = bfd_openw (name, TARGET_FORMAT)))
(gdb) s
bfd_openw (filename=0x8155a45 "a.out", target=0x8156d6c "elf32-powerpcle")
    at ../../src/bfd/opncls.c:348
348       bfd_set_error (bfd_error_system_call);
(gdb) n
353       nbfd = _bfd_new_bfd ();
(gdb) n
354       if (nbfd == NULL)
(gdb) n
357       target_vec = bfd_find_target (target, nbfd);
(gdb) n
358       if (target_vec == NULL)
(gdb) 
371           objalloc_free ((struct objalloc *) nbfd->memory);
(gdb) 
372           free (nbfd);
(gdb) 
373           return NULL;
(gdb) 
377     }
(gdb) n
output_file_create (name=0x8155a45 "a.out") at
../../src/gas/output-file.c:52
52            as_perror ("FATAL: Can't create %s", name);
(gdb) n
Assembler messages:
FATAL: Can't create a.out: Invalid bfd target
53            exit (EXIT_FAILURE);
(gdb) 

--joel

Re: binutils 2.9 powerpc-rtems breakage

[Ian Lance Taylor]

   Date: Tue, 14 Apr 1998 13:17:20 -0500 (CDT)
   From: Joel Sherrill <joel@OARcorp.com>

   bfd_openw (filename=0x8155a45 "a.out", target=0x8156d6c "elf32-powerpcle")
       at ../../src/bfd/opncls.c:348

OK, so why isn't elf32-powerpcle in your target list?

It would normally be there because of a -DSELECT_VECS argument when
targets.c was compiled.

Are you using shared libraries by any chance.  Somebody has already
pointed out a shared library problem in the 2.9 release: the name of
the library does not include the target name, so if you build and
install BFD more than once using --enable-shared, then the new library
will overwrite the old one.

Personally, I think the right solution is to just build BFD once using
--enable-targets, but building it multiple ones ought to work as well,
so this is a bug.

Ian

Re: binutils 2.9 powerpc-rtems breakage

[Joel Sherrill]

On Tue, 14 Apr 1998, Ian Lance Taylor wrote:

> OK, so why isn't elf32-powerpcle in your target list?

I do not know.  I have not been tinkering with anything.  

In fact, bfd/config.bfd has this:

  powerpc-*-*bsd* | powerpc-*-elf* | powerpc-*-sysv4* | powerpc-*-eabi* |
\
  powerpc-*-solaris2* | powerpc-*-linux-gnu* | powerpc-*-rtems*)
    targ_defvec=bfd_elf32_powerpc_vec
    targ_selvecs="rs6000coff_vec bfd_elf32_powerpcle_vec
bfd_powerpcle_pei_vec bfd_powerpc_pei_vec bfd_powerpcle_pe_vec
bfd_powerpc_pe_vec ppcboot_vec"

So anything on powerpc-eabi and powerpc-rtems should behave the same.

> It would normally be there because of a -DSELECT_VECS argument when
> targets.c was compiled.

OK.  

> Are you using shared libraries by any chance.  Somebody has already
> pointed out a shared library problem in the 2.9 release: the name of
> the library does not include the target name, so if you build and
> install BFD more than once using --enable-shared, then the new library
> will overwrite the old one.

I have not configured with --enable-shared.  So if it happened, it was the
default case.  I am on a RedHat x86 linux box if that makes any
difference. 

I build a lot of targets but always use different --prefix options.  I
don't think this problem is mine but it could be.

Is there anything else I could look at in gdb to figure out which vectors
are available?  Would that be a clue?

> Personally, I think the right solution is to just build BFD once using
> --enable-targets, but building it multiple ones ought to work as well,
> so this is a bug.

I have managed to build all the RTEMS configuration except the mips64orion
and powerpc ones.  Both of them are showing problems during multilib
builds of libgcc*.a.

--joel

Re: binutils 2.9 powerpc-rtems breakage

[Ian Lance Taylor]

   Date: Tue, 14 Apr 1998 13:56:21 -0500 (CDT)
   From: Joel Sherrill <joel@OARcorp.com>

   On Tue, 14 Apr 1998, Ian Lance Taylor wrote:

   > OK, so why isn't elf32-powerpcle in your target list?

   I do not know.  I have not been tinkering with anything.  

I meant to suggest that that is what you should look into next.

I don't have this problem, so you have to debug it yourself.

   > It would normally be there because of a -DSELECT_VECS argument when
   > targets.c was compiled.

   OK.  

So, build BFD, and see what -DSELECT_VECS look like when targets.c is
compiled.

   Is there anything else I could look at in gdb to figure out which vectors
   are available?  Would that be a clue?

You can see which vectors are available by looking at the contents of
the array bfd_target_vector.

Ian

Re: binutils 2.9 powerpc-rtems breakage

[Joel Sherrill]

Thanks. 

On Tue, 14 Apr 1998, Ian Lance Taylor wrote:

>    I do not know.  I have not been tinkering with anything.  
> 
> I meant to suggest that that is what you should look into next.
> 
> I don't have this problem, so you have to debug it yourself.
> 

I am checking into this further.  

FWIW, I get exactly the same problem building powerpc-eabi.  

If I built adding -static to CFLAGS would that help narrow down the
problem?

--joel

binutils 2.9 powerpc-rtems breakage

[Joel Sherrill]

I switched binutils 2.9 in my tree for gas-980314 and was unable to
complete a one-tree style build of binutils 2.9, egcs 1.0.2, and newlib
1.8.0.  The compilation aborted when trying to compile libgcc2.c for
_muldi3.  I cut the command down to the following:

/usr1/rtems/work/tools/build-powerpc-tools/gcc/xgcc \
  -B/usr1/rtems/work/tools/build-powerpc-tools/gcc/ -O2  -DCROSS_COMPILE \
  -DIN_GCC    -O2 -I./include   -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED \
  -fexceptions -Dinhibit_libc   -mlittle -mrelocatable-lib -mno-eabi \
  -mstrict-align -I. -I../../src/gcc -I../../src/gcc/config -DL_muldi3 \
      ../../src/gcc/libgcc2.c -c -v

which produces the following output:

Reading specs from /usr1/rtems/work/tools/build-powerpc-tools/gcc/specs
gcc version egcs-2.90.27 980315 (egcs-1.0.2 release)
 /usr1/rtems/work/tools/build-powerpc-tools/gcc/cpp -lang-c -v -I./include
-I. -I../../src/gcc -I../../src/gcc/config -isystem
/usr1/rtems/work/tools/build-powerpc-tools/gcc/include -undef -D__GNUC__=2
-D__GNUC_MINOR__=90 -DPPC -Drtems -D__rtems__ -D__PPC__ -D__rtems__
-D__rtems__ -D__PPC -D__rtems -Asystem(rtems) -Acpu(powerpc)
-Amachine(powerpc) -D__CHAR_UNSIGNED__ -D__OPTIMIZE__ -g1 -D_RELOCATABLE
-D_CALL_SYSV -D_LITTLE_ENDIAN -D__LITTLE_ENDIAN__ -Amachine(littleendian)
-D_ARCH_PPC -DCROSS_COMPILE -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-Dinhibit_libc -DL_muldi3 ../../src/gcc/libgcc2.c /tmp/cca06464.i
GNU CPP version egcs-2.90.27 980315 (egcs-1.0.2 release) (PowerPC
Embedded)
#include "..." search starts here:
#include <...> search starts here:
 include
 .
 ../../src/gcc
 ../../src/gcc/config
 /usr1/rtems/work/tools/build-powerpc-tools/gcc/include

/home/joel/egcs-1.0.2/powerpc-rtems/lib/gcc-lib/powerpc-rtems/egcs-2.90.27/include
 /home/joel/egcs-1.0.2/powerpc-rtems/powerpc-rtems/include
End of search list.
 /usr1/rtems/work/tools/build-powerpc-tools/gcc/cc1 /tmp/cca06464.i -quiet
-dumpbase libgcc2.c -mlittle -mrelocatable-lib -mno-eabi -mstrict-align
-g1 -O2 -O2 -version -fexceptions -o /tmp/cca06464.s
GNU C version egcs-2.90.27 980315 (egcs-1.0.2 release) (powerpc-rtems)
compiled by GNU C version 2.7.2.3.
 /usr1/rtems/work/tools/build-powerpc-tools/gcc/as -mppc -V -Qy
-mrelocatable-lib -mlittle -o libgcc2.o /tmp/cca06464.s
GNU assembler version 2.9 (powerpc-rtems), using BFD version 2.9
Assembler messages:
FATAL: Can't create libgcc2.o: Invalid bfd target

1 returned

I can produce a .s file using -s and then assemble that file with:

./as -mppc -V -Qy -mrelocatable-lib libgcc2.s

which indicates to me that somehow the rtems configuration lost support
for the -mlittle option.  powerpc-rtems should be identical to
powerpc-eabi if that trips anyone's memory.

Thanks.


--joel
Joel Sherrill                    Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985