Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.

Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.

[H . J . Lu]

ELFOSABI_MONTEREY has been replaced by ELFOSABI_AIX. I have checked in
patches to change all ELFOSABI_MONTEREY to ELFOSABI_AIX.

BTW, ELFOSABI_NONE, ELFOSABI_HPUX, ELFOSABI_NETBSD, ELFOSABI_LINUX,
ELFOSABI_HURD, ELFOSABI_SOLARIS, ELFOSABI_AIX, ELFOSABI_IRIX,
ELFOSABI_FREEBSD, ELFOSABI_TRU64, ELFOSABI_MODESTO and ELFOSABI_OPENBSD
will be moved from psABI to gABI. The first 128 entries in EI_OSABI
will be reserved for gABI and the last 28 entries will be for psABI. I
saw

#define ELFOSABI_STANDALONE 255 /* Standalone (embedded) application */
#define ELFOSABI_ARM   97               /* ARM */

in include/elf/common.h. They will violate the new gABI.

BTW, the EI_OSABI byte is used to tell how to interpret those fields
and values which are not defined by gABI nor psABI. It is not to tell
on which platform the binary is targeted. I am not sure if ELFOSABI_ARM
and ELFOSABI_STANDALONE are proper uses for this field. Should we fix
them?


-- 
H.J. Lu (hjl@valinux.com)
---
Index: binutils/ChangeLog
===================================================================
RCS file: /cvs/src/src/binutils/ChangeLog,v
retrieving revision 1.222
diff -u -p -r1.222 ChangeLog
--- ChangeLog	2000/11/19 20:57:42	1.222
+++ ChangeLog	2000/11/20 23:39:37
@@ -1,3 +1,8 @@
+2000-11-20  H.J. Lu  <hjl@gnu.org>
+
+	* readelf.c (get_osabi_name): Change ELFOSABI_MONTEREY to
+	ELFOSABI_AIX.
+
 2000-11-17  Richard Henderson  <rth@redhat.com>
 
 	* readelf.c (display_debug_lines): Adjust last change to
Index: binutils/readelf.c
===================================================================
RCS file: /cvs/src/src/binutils/readelf.c,v
retrieving revision 1.72
diff -u -p -r1.72 readelf.c
--- readelf.c	2000/11/19 20:57:42	1.72
+++ readelf.c	2000/11/20 23:39:45
@@ -2087,7 +2087,7 @@ get_osabi_name (osabi)
     case ELFOSABI_LINUX:      return _("UNIX - Linux");
     case ELFOSABI_HURD:       return _("GNU/Hurd");
     case ELFOSABI_SOLARIS:    return _("UNIX - Solaris");
-    case ELFOSABI_MONTEREY:   return _("UNIX - Monterey");
+    case ELFOSABI_AIX:        return _("UNIX - AIX");
     case ELFOSABI_IRIX:       return _("UNIX - IRIX");
     case ELFOSABI_FREEBSD:    return _("UNIX - FreeBSD");
     case ELFOSABI_TRU64:      return _("UNIX - TRU64");
Index: gdb/ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.789
diff -u -p -r1.789 ChangeLog
--- ChangeLog	2000/11/20 20:33:52	1.789
+++ ChangeLog	2000/11/20 23:39:52
@@ -1,3 +1,8 @@
+2000-11-20  H.J. Lu  <hjl@gnu.org>
+
+	* ia64-tdep.c (gdbarch_tdep): Change reference from
+	ELFOSABI_MONTEREY to ELFOSABI_AIX.
+
 2000-11-20  Peter Schauer  <pes@regent.e-technik.tu-muenchen.de>
 
 	* c-valprint.c (print_function_pointer_address):  New function
Index: gdb/ia64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/ia64-tdep.c,v
retrieving revision 1.10
diff -u -p -r1.10 ia64-tdep.c
--- ia64-tdep.c	2000/11/08 04:12:40	1.10
+++ ia64-tdep.c	2000/11/20 23:39:55
@@ -226,7 +226,7 @@ struct frame_extra_info
 struct gdbarch_tdep
   {
     int os_ident;	/* From the ELF header, one of the ELFOSABI_
-                           constants: ELFOSABI_LINUX, ELFOSABI_MONTEREY,
+                           constants: ELFOSABI_LINUX, ELFOSABI_AIX,
 			   etc. */
     CORE_ADDR (*sigcontext_register_address) (CORE_ADDR, int);
     			/* OS specific function which, given a frame address
Index: include/elf/ChangeLog
===================================================================
RCS file: /cvs/src/src/include/elf/ChangeLog,v
retrieving revision 1.71
diff -u -p -r1.71 ChangeLog
--- ChangeLog	2000/11/16 22:48:14	1.71
+++ ChangeLog	2000/11/20 23:39:58
@@ -1,3 +1,8 @@
+2000-11-20  H.J. Lu  <hjl@gnu.org>
+
+	* common.h (ELFOSABI_MONTEREY): Renamed to ...
+	(ELFOSABI_AIX): This.
+
 2000-11-16  Richard Henderson  <rth@redhat.com>
 
 	Update relocations per August psABI docs.
Index: include/elf/common.h
===================================================================
RCS file: /cvs/src/src/include/elf/common.h,v
retrieving revision 1.23
diff -u -p -r1.23 common.h
--- common.h	2000/07/20 15:44:56	1.23
+++ common.h	2000/11/20 23:39:59
@@ -64,7 +64,7 @@ Foundation, Inc., 59 Temple Place - Suit
 #define ELFOSABI_LINUX  3       /* GNU/Linux */
 #define ELFOSABI_HURD   4       /* GNU/Hurd */
 #define ELFOSABI_SOLARIS 6      /* Solaris */
-#define ELFOSABI_MONTEREY 7     /* Monterey */
+#define ELFOSABI_AIX    7       /* AIX */
 #define ELFOSABI_IRIX   8       /* IRIX */
 #define ELFOSABI_FREEBSD 9      /* FreeBSD */
 #define ELFOSABI_TRU64  10      /* TRU64 UNIX */

Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.

[Kevin Buettner]

On Nov 20,  3:59pm, H . J . Lu wrote:

> BTW, the EI_OSABI byte is used to tell how to interpret those fields
> and values which are not defined by gABI nor psABI. It is not to tell
> on which platform the binary is targeted. [...]

What is the proper method for determining the target platform?

(I know how to do it if it's linked against glibc, but not
otherwise...)

Kevin

Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.

[H . J . Lu]

On Mon, Nov 20, 2000 at 05:26:13PM -0700, Kevin Buettner wrote:
> On Nov 20,  3:59pm, H . J . Lu wrote:
> 
> > BTW, the EI_OSABI byte is used to tell how to interpret those fields
> > and values which are not defined by gABI nor psABI. It is not to tell
> > on which platform the binary is targeted. [...]
> 
> What is the proper method for determining the target platform?
> 
> (I know how to do it if it's linked against glibc, but not
> otherwise...)
> 

There is no easy way to tell, at least not from the EI_OSABI byte.
That is one reason why glibc did what it did. I was told people thought
about changing EI_OSABI to something else because of the confusion it
might lead to. But they decided against it.

BTW, in the modern world, there should be no static binaries. You can
tell which target a dynamic binary is for by checking PT_INTERP.


-- 
H.J. Lu (hjl@valinux.com)

Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.

[David O'Brien]

On Mon, Nov 20, 2000 at 04:39:40PM -0800, H . J . Lu wrote:
> BTW, in the modern world, there should be no static binaries. You can
> tell which target a dynamic binary is for by checking PT_INTERP.

So you're going to make the Linux `ldconfig' a dynamic binary?? ;-)
This Linux binary is the biggest reason FreeBSD needs an ELF branding
method.
 
-- 
-- David  (obrien@FreeBSD.org)

Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.

[H . J . Lu]

On Sat, Nov 25, 2000 at 12:40:44PM -0800, David O'Brien wrote:
> On Mon, Nov 20, 2000 at 04:39:40PM -0800, H . J . Lu wrote:
> > BTW, in the modern world, there should be no static binaries. You can
> > tell which target a dynamic binary is for by checking PT_INTERP.
> 
> So you're going to make the Linux `ldconfig' a dynamic binary?? ;-)
> This Linux binary is the biggest reason FreeBSD needs an ELF branding
> method.

FYI, gABI/psABI mainly cover dynamic binaries. They rarely mentions
static binaries if at all. Besides, there is nothing to stop you from
building a dynamic ldconfig. It is a trivial thing to do. But we,
Linux, won't use the dynamic ldconfig for obvious reasons.


-- 
H.J. Lu (hjl@valinux.com)

Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.

[David O'Brien]

On Sat, Nov 25, 2000 at 12:54:24PM -0800, H . J . Lu wrote:
> Besides, there is nothing to stop you from building a dynamic ldconfig.
> It is a trivial thing to do.

I know, but I'm not talking about the native FreeBSD /sbin/ldconfig
binary.

> But we, Linux, won't use the dynamic ldconfig for obvious reasons.

That is precisely the `ldconfig' I am speaking of.  In order for FreeBSD
to have a Linux binary compatibility mode, we install a subset of RedHat
binaries and libraries.  Thus there is a need to be able for the kernel
image loader to be able to recognize this binary.  The .note.ABI-tag is
one way.  So the poster (Kevin Buettner) that brought up the issue should
be pointed to that as a way to tell what syscall API a binary uses.
 
-- 
-- David  (obrien@FreeBSD.org)

Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.

[H . J . Lu]

On Sat, Nov 25, 2000 at 01:12:12PM -0800, David O'Brien wrote:
> 
> That is precisely the `ldconfig' I am speaking of.  In order for FreeBSD
> to have a Linux binary compatibility mode, we install a subset of RedHat
> binaries and libraries.

Then build/install/use a special dynamic Linux ldconfig for FreeBSD.

-- 
H.J. Lu (hjl@valinux.com)

Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.

[David O'Brien]

On Sat, Nov 25, 2000 at 04:00:20PM -0800, H . J . Lu wrote:
> > That is precisely the `ldconfig' I am speaking of.  In order for FreeBSD
> > to have a Linux binary compatibility mode, we install a subset of RedHat
> > binaries and libraries.
> 
> Then build/install/use a special dynamic Linux ldconfig for FreeBSD.

Oh get real.  I'd live to see the tables turned so that Linux had to deal
with FreeBSD binaries.  Then maybe we'd see a little help in engineering
a solution...

-- 
-- David  (obrien@FreeBSD.org)

Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.

[H . J . Lu]

On Sun, Nov 26, 2000 at 12:06:26PM -0800, Nick Clifton wrote:
> Hi H.J.,
> 
> : We can submit it. But I don't know if the name of ELFOSABI_ARM makes
> : any senses. Basically it is hard for the third party ELF tools.
> : to interpret ELFOSABI_ARM. How about we ask to change the gABI range
> : from 0 - 127 to 0 - 63 or 0 - 95?
> 
> Fine by me.  I would like the arm-elf toolchains to conform to the
> gABI if possible... :-)
> 
> Since you are on the committee, can I just ask you to do this, or do I
> have to do something else ?
> 

Done. I have submitted the request to change the gABI range from
0 - 127 to 0 - 63 or 0 - 95.

-- 
H.J. Lu (hjl@valinux.com)

Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.

[Nick Clifton]

Hi H.J.,

: We can submit it. But I don't know if the name of ELFOSABI_ARM makes
: any senses. Basically it is hard for the third party ELF tools.
: to interpret ELFOSABI_ARM. How about we ask to change the gABI range
: from 0 - 127 to 0 - 63 or 0 - 95?

Fine by me.  I would like the arm-elf toolchains to conform to the
gABI if possible... :-)

Since you are on the committee, can I just ask you to do this, or do I
have to do something else ?

Cheers
	Nick

Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.

[H . J . Lu]

On Fri, Nov 24, 2000 at 01:36:59PM -0800, Nick Clifton wrote:
> Hi Guys,
> 
> : >   #define ELFOSABI_ARM 129
> : > 
> : > that should work shouldn't it ?
> : 
> : You will break binary compatibility since the ld.so tests for this value.
> 
> Ah, in which case maybe we should try to get
> 
>  #define ELFOSABI_ARM 97
> 
> registered as a valid ELF gABI value ?  How is this done ?
> 

We can submit it. But I don't know if the name of ELFOSABI_ARM makes
any senses. Basically it is hard for the third party ELF tools.
to interpret ELFOSABI_ARM. How about we ask to change the gABI range
from 0 - 127 to 0 - 63 or 0 - 95?

-- 
H.J. Lu (hjl@valinux.com)

Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.

[Nick Clifton]

Hi Guys,

: >   #define ELFOSABI_ARM 129
: > 
: > that should work shouldn't it ?
: 
: You will break binary compatibility since the ld.so tests for this value.

Ah, in which case maybe we should try to get

 #define ELFOSABI_ARM 97

registered as a valid ELF gABI value ?  How is this done ?

Cheers
	Nick

Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.

[Ulrich Drepper]

Nick Clifton <nickc@redhat.com> writes:

>   #define ELFOSABI_ARM 129
> 
> that should work shouldn't it ?

You will break binary compatibility since the ld.so tests for this value.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.

[Nick Clifton]

Hi H.J.,

: #define ELFOSABI_STANDALONE 255 /* Standalone (embedded) application */
: #define ELFOSABI_ARM   97               /* ARM */
: 
: in include/elf/common.h. They will violate the new gABI.
: 
: BTW, the EI_OSABI byte is used to tell how to interpret those fields
: and values which are not defined by gABI nor psABI. It is not to tell
: on which platform the binary is targeted. I am not sure if ELFOSABI_ARM
: and ELFOSABI_STANDALONE are proper uses for this field. Should we fix
: them?

I am not sure about the ELFOSABI_STANDALONE value, but the arm-elf
toolchain definitely uses the ELFOSABI_ARM value.  (See
elf32_arm_final_link_relocate).  In fact the code just relies upon
there being a non-zero value in this field, so if we changed the
definition to:

  #define ELFOSABI_ARM 129

that should work shouldn't it ?

Given the current use of this field by the elf32-arm.h code though
(to distinguish between an old, buggy implementation of the ARM ELF
ABI and the current, working implementation), I thought that perhaps
it ought to be changed to a value in EI_ABIVERSION.  However the
latest documentation I have for this field says that it should only
have a non-zero value if there is a non-zero value in EI_OSABI, so
that wouldn't work.

Cheers
	Nick