[rfa:] CRIS port part 7/8: binutils (readelf.c tweak consequences)

[rfa:] CRIS port part 7/8: binutils (readelf.c tweak consequences)

[Hans-Peter Nilsson]

Makefile.am needs rebuilding since adding include of include/elf/cris.h.
Ditto binutils.pot, but if so requested I'll leave it out.

Makefile.am changes aren't included here, since they're autogenerated.

Ok to commit?

2000-07-18  Hans-Peter Nilsson  <hp@axis.com>

	* readelf.c: Include elf/cris.h.
	(guess_is_rela): Handle EM_CRIS.
	(dump_relocations): Ditto.
	(get_machine_name): Ditto.
	* Makefile.am: Rebuild dependencies.
	* Makefile.in: Regenerate.
	* po/binutils.pot: Regenerate.

Index: binutils/readelf.c
===================================================================
RCS file: /cvs/src/src/binutils/readelf.c,v
retrieving revision 1.61
diff -p -c -r1.61 readelf.c
*** readelf.c	2000/07/10 14:51:04	1.61
--- readelf.c	2000/07/18 18:59:48
***************
*** 71,76 ****
--- 71,77 ----
  #include "elf/pj.h"
  #include "elf/avr.h"
  #include "elf/ia64.h"
+ #include "elf/cris.h"
  
  #include "bucomm.h"
  #include "getopt.h"
*************** guess_is_rela (e_machine)
*** 565,570 ****
--- 566,572 ----
      case EM_MCORE:
      case EM_IA_64:
      case EM_AVR:
+     case EM_CRIS:
        return TRUE;
  
      case EM_MMA:
*************** dump_relocations (file, rel_offset, rel_
*** 879,884 ****
--- 881,890 ----
  	case EM_IA_64:
  	  rtype = elf_ia64_reloc_type (type);
  	  break;
+ 
+ 	case EM_CRIS:
+ 	  rtype = elf_cris_reloc_type (type);
+ 	  break;
  	}
  
        if (rtype == NULL)
*************** get_machine_name (e_machine)
*** 1242,1247 ****
--- 1248,1254 ----
      case EM_ST19:     		return "STMicroelectronics ST19 8-bit microcontroller";
      case EM_VAX:      		return "Digital VAX";
      case EM_AVR:                return "Atmel AVR 8-bit microcontroller";
+     case EM_CRIS:		return "Axis Communications 32-bit embedded processor";
      default:
        sprintf (buff, _("<unknown>: %x"), e_machine);
        return buff;

brgds, H-P

Bad bug in ar (or ranlib?)

[Cyrille Artho]

Hi all,
under Linux/i686/g++, I try to compile a large set of C++ files that
compile under Solaris with Sun's latest compiler (SunWspro version 5).
The C++ files make no use of exceptions or templates. They do, though,
include a C API in the C++ files, and C code (.c) and header files,
which partially contain C++ code in return (no, I did not write that
myself). This means that the source files have abundant 'extern "C"'
declarations, and even some 'extern "C++"' parts.
When I try to compile the entire bunch of files, the output is
inconsistent! The source files are the same, though, and the time is not
included as a command line option for the version string (only the date
is used).

First, the .o files (from g++ -c) slightly differ, but I guess this is
because g++ uses some short random strings for the object file. I think
all .o files I got are always working (I could not test them every
time). The size of the .o files is always the same, and the first byte
that differs always has the same offset (but different .o files have
offsets ranging from ~30 to several 10K bytes).

However, when I build a static library with ar, the library sometimes
differs in size, and as a result of that is not working! I get numerous
errors like
--
BFD: ../objlx/UTraceOut.o: invalid string offset 1769472 >= 958 for
section `.shstrtab'
..
BFD: UTraceOut.o: invalid string offset 1769472 >= 958 for section
`.shstrtab'
all the time
--
I get about 30 such error messages, once for "ar" (where it says
../objlx) and once again for ranlib which encounters a broken archive.
The error messages do *not* always occur at the same place (not even in
the same object file).
When I run 'nm' later to check the .a file, I also get (before the other
error messages):
nm: utablecmp.o: File truncated
nm: UListPool.o: File truncated

I suspect this is a nasty bug in ar, and may be because g++ uses
different (rather short) strings for connecting the various parts of C++
templates/objects/operators/methods during each compile time. Possibly
the handling of such symbols in 'ar' is not robust enough, and some
constellations of these short g++ strings cause it to fail.
I sometimes also get a file like stX7GTrk during the build process
(output by 'ar', I guess). I am afraid I cannot provide the files for
inspection, because the program I work with is not Open Source; but I
have made a copy of one faulty run, and can run any sets of commands
that may give more insight into this.
Needless to say, the resulting binary produces segmentation faults in
strange places. Different binaries from different compile runs never
have the same size (if they include a static library), and vary in size
up to 30 KB (about 1%)!
--
Regards,
Cyrille Artho - http://artho.com
Alcohol is the anesthesia by which we endure the operation of life.
                -- George Bernard Shaw

Re: Bad bug in ar (or ranlib?)

[Geoff Keating]

> Mailing-List: contact binutils-help@sourceware.cygnus.com; run by ezmlm
> List-Unsubscribe: < mailto:binutils-unsubscribe-geoffk=cygnus.com@sources.redhat.com >
> List-Subscribe: < mailto:binutils-subscribe@sources.redhat.com >
> List-Archive: < http://sources.redhat.com/ml/binutils/ >
> List-Post: < mailto:binutils@sources.redhat.com >
> List-Help: < mailto:binutils-help@sources.redhat.com >, < http://sources.redhat.com/ml/#faqs >
> Date: Wed, 19 Jul 2000 10:34:14 +0200
> From: Cyrille Artho <cartho@mordor.ch>
> X-Accept-Language: en
> 
> Hi all,
> under Linux/i686/g++, I try to compile a large set of C++ files that
> compile under Solaris with Sun's latest compiler (SunWspro version 5).
> The C++ files make no use of exceptions or templates. They do, though,
> include a C API in the C++ files, and C code (.c) and header files,
> which partially contain C++ code in return (no, I did not write that
> myself). This means that the source files have abundant 'extern "C"'
> declarations, and even some 'extern "C++"' parts.
> When I try to compile the entire bunch of files, the output is
> inconsistent! The source files are the same, though, and the time is not
> included as a command line option for the version string (only the date
> is used).

They shouldn't vary much.  Sometimes g++ does need to include a short
random string in an object file, but other than that if you give it
exactly the same input it should produce exactly the same output.
You can usually spot the random strings because the files will only
differ in about 8 consecutive bytes, which will be ASCII characters.

> First, the .o files (from g++ -c) slightly differ, but I guess this is
> because g++ uses some short random strings for the object file. I think
> all .o files I got are always working (I could not test them every
> time). The size of the .o files is always the same, and the first byte
> that differs always has the same offset (but different .o files have
> offsets ranging from ~30 to several 10K bytes).
> 
> However, when I build a static library with ar, the library sometimes
> differs in size, and as a result of that is not working! I get numerous
> errors like
> --
> BFD: ../objlx/UTraceOut.o: invalid string offset 1769472 >= 958 for
> section `.shstrtab'
> ..
> BFD: UTraceOut.o: invalid string offset 1769472 >= 958 for section
> `.shstrtab'
> all the time
> --
> I get about 30 such error messages, once for "ar" (where it says
> ../objlx) and once again for ranlib which encounters a broken archive.
> The error messages do *not* always occur at the same place (not even in
> the same object file).
> When I run 'nm' later to check the .a file, I also get (before the other
> error messages):
> nm: utablecmp.o: File truncated
> nm: UListPool.o: File truncated

Now, that's a more serious problem.  Can you come up with a short testcase?

-- 
- Geoffrey Keating <geoffk@cygnus.com>