more on powerpc-rtems ar failure

more on powerpc-rtems ar failure

[Joel Sherrill]

Thanks for the earlier fix.  

This problem is another -mlittle one.  Here is a test case:

------------------ assembly file used to duplicate this -----
        .file   "j.s"

        .section ".text"
        .align 2
        .globl f
f:
        blr
----------------------- end of file

../gas/as-new -mlittle -o j.o j.s
../binutils/ar rc j.a j.o
../binutils/ar rc j.a j.o
../binutils/ar: j.a: Invalid operation

Tracing in gdb, it looks like the format of the file is not automatically
recognized:


Breakpoint 4, main (argc=4, argv=0xbffff9dc) at
../../src/binutils/ar.c:555
555           arch = open_inarch (inarch_filename,
(gdb) s
open_inarch (archive_filename=0xbffffaf8 "j.a", file=0xbffffafc "j.o")
    at ../../src/binutils/ar.c:614
614       bfd_set_error (bfd_error_no_error);
(gdb) n
616       target = NULL;
(gdb) 
618       if (stat (archive_filename, &sbuf) != 0)
(gdb) 
661       arch = bfd_openr (archive_filename, target);
(gdb) 
662       if (arch == NULL)
(gdb) 
668       if (! bfd_check_format_matches (arch, bfd_archive, &matching))
(gdb) 
670           bfd_nonfatal (archive_filename);
(gdb) 
/usr1/rtems/work/tools/build-powerpc-tools/gcc/../binutils/ar: j.a:
Invalid operation
671           if (bfd_get_error () ==
bfd_error_file_ambiguously_recognized)
(gdb) 
676           xexit (1);
(gdb) 

----------------------------------

I confirmed this by:

rm j.a
../gas/as-new -mlittle -o j.o j.s
./binutils/ar rc j.a j.o
GNUTARGET=elf32-powerpcle ../binutils/ar rc j.a j.o

The mips64orion failure is the same message in the same place in the gcc
libgcc2 build.  I suspect it is the same type of failure but need to
confirm it.

I think this is a bit better bug report than I started with on the
targets.c one.  Sorry about that.

--joel

Re: more on powerpc-rtems ar failure

[Ian Lance Taylor]

   Date: Thu, 16 Apr 1998 15:26:16 -0500 (CDT)
   From: Joel Sherrill <joel@OARcorp.com>

   This problem is another -mlittle one.  Here is a test case:

   ------------------ assembly file used to duplicate this -----
	   .file   "j.s"

	   .section ".text"
	   .align 2
	   .globl f
   f:
	   blr
   ----------------------- end of file

   ../gas/as-new -mlittle -o j.o j.s
   ../binutils/ar rc j.a j.o
   ../binutils/ar rc j.a j.o
   ../binutils/ar: j.a: Invalid operation

Was this ar build with --enable-targets=all?  It's hard to recommend
using such tools for general use.  There are too many ambiguities
among different object file formats.  You should instead spell out the
precise set of targets you want to support.

Still, ar ought to report a better error message, so there may be
something different going on here.

However, I can't recreate the problem using an ar configured for
powerpc-eabi.

Ian

Re: more on powerpc-rtems ar failure

[Joel Sherrill]

On Thu, 16 Apr 1998, Ian Lance Taylor wrote:

> Was this ar build with --enable-targets=all?  

Yes, I did build with --enable-targets=all.  I build the tools with a
script and that option has been in there a long time.

I have tried it again without the --enable-targets=all option and it is
already up to newlib.  So this must be the culprit.

> It's hard to recommend using such tools for general use.  There are too
> many ambiguities among different object file formats.  You should
> instead spell out the precise set of targets you want to support. 

I can see that it would be hard to figure it out.  There are a LOT of BFD
entries.  THis will probably speed up the build as well as reduce the size
of the executables.

We release have instructions and a script to build the tools for RTEMS
users, so please understand where the following questions are coming from.
When I delete --enable-targets=all, I am doing it for every RTEMS user. :)

Will taking the default result in getting all the formats for a particular
CPU?  I have tried to encourage the use of CPU-rtems for all users of CPU
and then have them use objcopy to produce the exact format required by a
board.   For example, does m68k-coff (aka m68k-rtems) also include
at least m68k-aout, srecords, binary -- with m68k-elf a plus.   On CPUs
with both big and little endian, does it get all the "same endian"
formats? 

For the powerpc-rtems at least, the list of default supported targets is
more than good enough.

I lean toward not specifying any targets since I have 10 RTEMS targets
already and couldn't figure out the exact list.  Not to mention I will
need to add two new ones soon -- there are ARM and H8 ports about ready to
be submitted.

> Still, ar ought to report a better error message, so there may be
> something different going on here.

Even if it had printed out something like "can't figure out the object
format of the library", it still would not tell me that it was
there was ambiguity because of "--enable-targets=all".

FWIW I can duplicate the problem using the same procedure on the
mips64orion-rtems target with the "-EL" option to gcc/as and the GNU
target of elf32-littlemips. 

> However, I can't recreate the problem using an ar configured for
> powerpc-eabi.

Probably without --enable-targets=all?

Thanks.  I have learned a lot this time.  I have wanted to treat the BFD
as black magic (which it is) but this has been enlightening.  

--joel

Re: more on powerpc-rtems ar failure

[Ian Lance Taylor]

   Date: Thu, 16 Apr 1998 16:30:24 -0500 (CDT)
   From: Joel Sherrill <joel@OARcorp.com>

   Will taking the default result in getting all the formats for a particular
   CPU?  I have tried to encourage the use of CPU-rtems for all users of CPU
   and then have them use objcopy to produce the exact format required by a
   board.   For example, does m68k-coff (aka m68k-rtems) also include
   at least m68k-aout, srecords, binary -- with m68k-elf a plus.

In general, no.  You can see which formats will be supported for a
particular configuration target by looking in config.bfd.  The
s-records and binary formats are always supported, as are the tekhex
and Intel hex formats.  For your particular example of m68k-coff, you
will get support for m68k-coff, versados, and m68k IEEE, but not
m68k-aout or m68k-elf.

   On CPUs
   with both big and little endian, does it get all the "same endian"
   formats? 

It normally gets both big and little endian variants, if that is what
you are asking.

Ian

Re: more on powerpc-rtems ar failure

[Joel Sherrill]

On Thu, 16 Apr 1998, Ian Lance Taylor wrote:

> In general, no.  You can see which formats will be supported for a
> particular configuration target by looking in config.bfd.  The
> s-records and binary formats are always supported, as are the tekhex
> and Intel hex formats.  For your particular example of m68k-coff, you
> will get support for m68k-coff, versados, and m68k IEEE, but not
> m68k-aout or m68k-elf.

This seems like a pretty reasonable default to start with.  I will ask the
testers what formats they would like to see enabled by default for
CPU-rtems and then change config.bfd accordingly.  I suspect that the
biggest change will be to support a.out, coff, and elf.  It is common to
find loaders on embedded systems which know a.out or coff but you don't
necessarily want to use that as your native format.

Would this be a general enough change where the target CPU-rtems is based
on would also be acceptable to have this behavior?  For example, m68k-coff
and m68k-rtems are essentially the same.  Would it be acceptable to add
m68k-aout to both?

>    On CPUs
>    with both big and little endian, does it get all the "same endian"
>    formats? 
> 
> It normally gets both big and little endian variants, if that is what
> you are asking.

Great!!

Thanks again.  

--joel

Re: more on powerpc-rtems ar failure

[Ian Lance Taylor]

   Date: Thu, 16 Apr 1998 16:49:49 -0500 (CDT)
   From: Joel Sherrill <joel@OARcorp.com>

   Would this be a general enough change where the target CPU-rtems is based
   on would also be acceptable to have this behavior?  For example, m68k-coff
   and m68k-rtems are essentially the same.  Would it be acceptable to add
   m68k-aout to both?

No, not really.  Very few people are going to want support for both.
You do only because you are distributing the results to large numbers
of people.  It's kind of a hack that m68k-coff builds m68k-ieee
support.

Ian

Re: more on powerpc-rtems ar failure

[Joel Sherrill]

On Thu, 16 Apr 1998, Ian Lance Taylor wrote:

> No, not really.  Very few people are going to want support for both.
> You do only because you are distributing the results to large numbers
> of people.  It's kind of a hack that m68k-coff builds m68k-ieee
> support.

OK.  Then if you do not mind, I will let CPU-rtems deviate sometimes.  I
think m68k-rtems will for m68k-aout since a lot of m68k loaders only know
a.out. I suspect the i386 may as well but don't know for sure and will let
folks gripe.

This will definitely be something I don't change until it impacts someone.
:)

Thanks for your advice.  This is the kind of information only someone
intimiately famililar with something can provide.

--joel

Re: more on powerpc-rtems ar failure

[Ian Lance Taylor]

   Date: Thu, 16 Apr 1998 15:26:16 -0500 (CDT)
   From: Joel Sherrill <joel@OARcorp.com>

   This problem is another -mlittle one.  Here is a test case:

   ------------------ assembly file used to duplicate this -----
	   .file   "j.s"

	   .section ".text"
	   .align 2
	   .globl f
   f:
	   blr
   ----------------------- end of file

   ../gas/as-new -mlittle -o j.o j.s
   ../binutils/ar rc j.a j.o
   ../binutils/ar rc j.a j.o
   ../binutils/ar: j.a: Invalid operation

Found the problem.

Ian

Index: archive.c
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/archive.c,v
retrieving revision 1.135
diff -u -r1.135 archive.c
--- archive.c	1998/03/27 21:30:25	1.135
+++ archive.c	1998/04/16 22:33:17
@@ -646,6 +646,8 @@
     {
       bfd_release (abfd, bfd_ardata (abfd));
       abfd->tdata.aout_ar_data = tdata_hold;
+      if (bfd_get_error () != bfd_error_system_call)
+	bfd_set_error (bfd_error_wrong_format);
       return NULL;
     }
 
@@ -653,6 +655,8 @@
     {
       bfd_release (abfd, bfd_ardata (abfd));
       abfd->tdata.aout_ar_data = tdata_hold;
+      if (bfd_get_error () != bfd_error_system_call)
+	bfd_set_error (bfd_error_wrong_format);
       return NULL;
     }
 

Re: more on powerpc-rtems ar failure

[Joel Sherrill]

Thanks.

On Thu, 16 Apr 1998, Ian Lance Taylor wrote:

> Found the problem.

Is this just that the code to check for "wrong format" was missing?  So
now it prints a better message?

Were you able to reproduce Eric Norum's Srecord split problem?  Did you
get all the information you wanted?

--joel

> Index: archive.c
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/bfd/archive.c,v
> retrieving revision 1.135
> diff -u -r1.135 archive.c
> --- archive.c	1998/03/27 21:30:25	1.135
> +++ archive.c	1998/04/16 22:33:17
> @@ -646,6 +646,8 @@
>      {
>        bfd_release (abfd, bfd_ardata (abfd));
>        abfd->tdata.aout_ar_data = tdata_hold;
> +      if (bfd_get_error () != bfd_error_system_call)
> +	bfd_set_error (bfd_error_wrong_format);
>        return NULL;
>      }
>  
> @@ -653,6 +655,8 @@
>      {
>        bfd_release (abfd, bfd_ardata (abfd));
>        abfd->tdata.aout_ar_data = tdata_hold;
> +      if (bfd_get_error () != bfd_error_system_call)
> +	bfd_set_error (bfd_error_wrong_format);
>        return NULL;
>      }
>  
> 

Re: more on powerpc-rtems ar failure

[Ian Lance Taylor]

   Date: Fri, 17 Apr 1998 07:55:05 -0500 (CDT)
   From: Joel Sherrill <joel@OARcorp.com>

   > Found the problem.

   Is this just that the code to check for "wrong format" was missing?  So
   now it prints a better message?

With the patch I sent, ar works correctly when configured with
--enable-targets=all.  It's still possible to have ambiguity problems
with --enable-targets=all, but this one wasn't an ambiguity problem.
It was a bug.

   Were you able to reproduce Eric Norum's Srecord split problem?  Did you
   get all the information you wanted?

Yes, I was able to reproduce it.  The bug appears to have been there
for a long time.  I haven't looked into fixing it yet.  The patch
would be to calculate the correct section size in setup_sections
rather than in copy_sections.

Ian

Re: more on powerpc-rtems ar failure

[Joel Sherrill]

On Fri, 17 Apr 1998, Ian Lance Taylor wrote:

>    Is this just that the code to check for "wrong format" was missing?  So
>    now it prints a better message?
> 
> With the patch I sent, ar works correctly when configured with
> --enable-targets=all.  It's still possible to have ambiguity problems
> with --enable-targets=all, but this one wasn't an ambiguity problem.
> It was a bug.

So powerpc-rtems should complete a build now with --enable-targets=all?

I am switching away from doing this based on your comments.

>    Were you able to reproduce Eric Norum's Srecord split problem?  Did you
>    get all the information you wanted?
> 
> Yes, I was able to reproduce it.  The bug appears to have been there
> for a long time.  I haven't looked into fixing it yet.  The patch
> would be to calculate the correct section size in setup_sections
> rather than in copy_sections.

Great.  We were not as concerned with when it was fixed as much as if the
report was reproducible and good enough to get fixed sometime.  Eric found
a work-around.

--joel

Re: more on powerpc-rtems ar failure

[Ian Lance Taylor]

   Date: Fri, 17 Apr 1998 10:53:27 -0500 (CDT)
   From: Joel Sherrill <joel@OARcorp.com>

   So powerpc-rtems should complete a build now with --enable-targets=all?

Yes.

   I am switching away from doing this based on your comments.

Yes, I would still advise avoiding --enable-targets=all unless you
really need support for all targets.  You're too likely to get into
weird problems.

Ian