NetBSD Problem Report #6545

Received: (qmail 6302 invoked from network); 8 Dec 1998 08:02:55 -0000
Message-Id: <199812080802.AAA22905@goldberry.poofy.goof.com>
Date: Tue, 8 Dec 1998 00:02:52 -0800 (PST)
From: agrier@poofy.goof.com
Reply-To: agrier@goldberry.poofy.goof.com
To: gnats-bugs@gnats.netbsd.org
Subject: file(1) reports invalid byte order for DECStation binaries
X-Send-Pr-Version: 3.95

>Number:         6545
>Category:       port-pmax
>Synopsis:       mips2+ binaries report MIPS R3000_BE or R3000_LE
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    port-pmax-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 08 00:05:01 +0000 1998
>Closed-Date:    Sat Jan 19 22:32:19 +0000 2008
>Last-Modified:  Sat Jan 19 22:32:19 +0000 2008
>Originator:     Aaron J. Grier
>Release:        1.3 and file <= 3.26
>Organization:
>Environment:
>Description:
	file(1) reports invalid byte order for DECStation binaries
	compiled with gcc.  DECStations are Little Endian, but file
	reports files as "MIPS R3000_BE - invalid byte order."
>How-To-Repeat:
	run file on any gcc compiled file on a DECStation:
	goldberry:~$ file /bin/sh
	/bin/sh: ELF 32-bit LSB executable, MIPS R3000_BE - invalid byte
	order, version 1, statically linked, stripped
>Fix:
	Fix the magic (5) database, I imagine, though maybe there's a problem
	with the source for the file command with regard to endianness.
>Release-Note:
>Audit-Trail:

From: "Aaron J. Grier" <agrier@poofy.goof.com>
To: gnats-bugs@netbsd.org
Cc:  Subject: port-pmax/6545
Date: Tue, 8 Dec 1998 00:17:25 -0800 (PST)

 Duh, I should've checked the port-mips gnats pr list before reporting this
 one, as even the fix is there in port-mips/4939.

 ----
   Aaron J. Grier  | "Not your ordinary poofy goof." | agrier@poofy.goof.com
       "A few compilers designed on and for the original IBM 370 series
        machines have a more effective register allocater than anything
        GCC has ever posessed." -- David S. Miller on linux-kernel


From: christos@zoulas.com (Christos Zoulas)
To: agrier@goldberry.poofy.goof.com, gnats-bugs@gnats.netbsd.org
Cc:  Subject: Re: port-pmax/6545: file(1) reports invalid byte order for DECStation binaries
Date: Tue, 8 Dec 1998 09:19:53 -0500

 On Dec 8, 12:02am, agrier@poofy.goof.com (agrier@poofy.goof.com) wrote:
 -- Subject: port-pmax/6545: file(1) reports invalid byte order for DECStation

 | 	file(1) reports invalid byte order for DECStation binaries
 | 	compiled with gcc.  DECStations are Little Endian, but file
 | 	reports files as "MIPS R3000_BE - invalid byte order."
 | >How-To-Repeat:
 | 	run file on any gcc compiled file on a DECStation:
 | 	goldberry:~$ file /bin/sh
 | 	/bin/sh: ELF 32-bit LSB executable, MIPS R3000_BE - invalid byte
 | 	order, version 1, statically linked, stripped
 | >Fix:
 | 	Fix the magic (5) database, I imagine, though maybe there's a problem
 | 	with the source for the file command with regard to endianness.

 That is correct. If you look at the ELF abi, file(1) is right and binutils
 is wrong.

 christos

From: "Aaron J. Grier" <agrier@poofy.goof.com>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: port-pmax/6545: file(1) reports invalid byte order for DECStation binaries
Date: Tue, 8 Dec 1998 13:05:54 -0800 (PST)

 On Tue, 8 Dec 1998, Christos Zoulas wrote:

 > On Dec 8, 12:02am, agrier@poofy.goof.com (agrier@poofy.goof.com) wrote:
 > | >Fix:
 > | 	Fix the magic (5) database, I imagine, though maybe there's a problem
 > | 	with the source for the file command with regard to endianness.
 > 
 > That is correct.

 So which is it? Does the magic database need to be fixed, or is there a
 problem with file's endianness routines?  Or is it binutils?

 > If you look at the ELF abi, file(1) is right and binutils is wrong. 

 So the problem is with binutils and not with file after all?

 I'm confused.

 Is this kind of silliness also related?:

 niobium:~$ file hello.mips1
 hello.mips1:    ELF 32-bit MSB mips-2 dynamic executable MIPS - version 1
 niobium:~$ file hello.mips2
 hello.mips2:    ELF 32-bit MSB mips-2 dynamic executable MIPS - version 1
 niobium:~$ file hello.mips3
 hello.mips3:    ELF 64-bit MSB mips-3 dynamic executable (not stripped) MIPS - version 1
 niobium:~$ uname -a
 IRIX niobium 6.2 03131015 IP20

 And on a pmax running 1998-10-25 snapshot with unadultered magic database:

 legolas:~/metro$ file hello.mips1; file hello.mips2; file hello.mips3
 hello.mips1: ELF 32-bit MSB executable, MIPS R3000_BE, version 1
 hello.mips2: ELF 32-bit MSB executable, MIPS R3000_BE, version 1
 hello.mips3: ELF 64-bit MSB executable, MIPS R3000_BE, version 1

 On pmax running 1998-10-25 _with_ adultered magic database:

 goldberry:~/metro$ file hello.mips1; file hello.mips2; file hello.mips3
 hello.mips1: ELF 32-bit MSB executable, MIPS R3000_BE, version 1
 hello.mips2: ELF 32-bit MSB executable, MIPS R3000_BE, version 1
 hello.mips3: ELF 64-bit MSB executable, MIPS R3000_BE, version 1

 shouldn't the mips3 file come up as R4x00?  According to cc on the SGI
 machine, the -mips3 flag should be producing R4x00 code...

 ----
   Aaron J. Grier  | "Not your ordinary poofy goof." | agrier@poofy.goof.com
       "A few compilers designed on and for the original IBM 370 series
        machines have a more effective register allocater than anything
        GCC has ever posessed." -- David S. Miller on linux-kernel





From: christos@zoulas.com (Christos Zoulas)
To: "Aaron J. Grier" <agrier@poofy.goof.com>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: port-pmax/6545: file(1) reports invalid byte order for DECStation binaries
Date: Wed, 9 Dec 1998 02:22:45 -0500

 On Dec 8,  1:05pm, agrier@poofy.goof.com ("Aaron J. Grier") wrote:
 -- Subject: Re: port-pmax/6545: file(1) reports invalid byte order for DECSta

 | On Tue, 8 Dec 1998, Christos Zoulas wrote:
 | 
 | > On Dec 8, 12:02am, agrier@poofy.goof.com (agrier@poofy.goof.com) wrote:
 | > | >Fix:
 | > | 	Fix the magic (5) database, I imagine, though maybe there's a problem
 | > | 	with the source for the file command with regard to endianness.
 | > 
 | > That is correct.
 | 
 | So which is it? Does the magic database need to be fixed, or is there a
 | problem with file's endianness routines?  Or is it binutils?
 | 
 | > If you look at the ELF abi, file(1) is right and binutils is wrong. 
 | 
 | So the problem is with binutils and not with file after all?
 | 
 | shouldn't the mips3 file come up as R4x00?  According to cc on the SGI
 | machine, the -mips3 flag should be producing R4x00 code...

 There is no separate elf code for MIPS R4000. If you dig in the web pages
 of SCO, you'll see all the defined codes for processors. This is the
 definitive list, and it is where I've copied the magic entries from.
 Binutils is wrong in this case.

 christos
Responsible-Changed-From-To: gnats-admin->port-pmax-maintainer 
Responsible-Changed-By: fair 
Responsible-Changed-When: Mon Dec 28 09:42:50 PST 1998 
Responsible-Changed-Why:  
This PR is the responsibility of the portmaster, 
not the GNATS database administrator. 

From: Jeff Smith <jeffs@geocast.com>
To: gnats-bugs@netbsd.org
Cc:  
Subject: Re: port-pmax/6545
Date: Fri, 18 Aug 2000 17:00:56 -0700 (PDT)

 I've updated the synopsis of this bug from "invalid endian" for little
 endian mips binaries to the R3000_BE/R3000_BE issue that was discussed
 in the bug.  The original PR has been closed as part of 4939.

 SGI at this part in the file just reports MIPS, but at least some
 linux distributions still say R3000_*.

 Since we now print mips-1 to mips-4 it seems we should just drop the
 whole R3000_* part since the endian is caputured in LSB vs MSB.  In
 this way, it is somewhat tied to 4939, and whatever the MIPS guys
 decided to do 10+ years ago.

State-Changed-From-To: open->closed
State-Changed-By: ad@narn.netbsd.org
State-Changed-When: Sat, 19 Jan 2008 22:32:19 +0000
State-Changed-Why:
- unclear if this is a bug.

- open for 10 years and unresolved.


>Unformatted:
 >System: NetBSD goldberry 1.3H NetBSD 1.3H (sys) #24: Sun Oct 25 14:36:22 PST 1998 agrier@goldberry:/usr/local/src/NetBSD/src/sys pmax

Home	PR Database Search