From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20470 invoked by alias); 18 Oct 2002 19:33:14 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 20424 invoked from network); 18 Oct 2002 19:33:12 -0000 Received: from unknown (HELO dair.pair.com) (209.68.1.49) by sources.redhat.com with SMTP; 18 Oct 2002 19:33:12 -0000 Received: (qmail 77384 invoked by uid 20157); 18 Oct 2002 19:33:10 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Oct 2002 19:33:10 -0000 Date: Fri, 18 Oct 2002 12:33:00 -0000 From: Hans-Peter Nilsson X-X-Sender: hp@dair.pair.com To: binutils@sources.redhat.com cc: Alan Modra , Matt Thomas , Ulrich Drepper Subject: Re: [Patch] sh64: Fix gas testsuite expected output In-Reply-To: <3DB0435B.50000@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-10/txt/msg00454.txt.bz2 On Fri, 18 Oct 2002, Ulrich Drepper wrote: > Alan Modra wrote: > > I believe the real test for a change in OSABI or ABIVERSION is: > > Will a consumer of ELF files, such as a linker, that properly handles > > ELF files conforming to the gABI and relevant psABI, be able to > > properly handle your particular ELF files? > As said many times, yes, this is the only use for this field. All other > marking of an ELF file must be done with other means and the method > agreed on a looong time ago is a special note segment. Sure, a .note section with identifying contents for a linked object, but that doesn't solve it for a REL (meaning non-linked) object. Or perhaps you didn't really mean the .note section? Suggestion: for REL (still meaning unlinked) objects have an empty section with a special name (keyed on machine-name and vendor name, like GNU as in GNU binutils, and on function) in each unlinked object, e.g. .SH.GNU.abi.gnulinux .SH.GNU.abi.standalone .SH.GNU.abi.netbsd (Names TBD; just examples.) Caveat: it doesn't solve the ambiguity for existing objects. I think we can live with that, if objects without such a section are treated as compatible with whatever context they are used in. This should keep backward compatibility, and above all, old tools won't hork when they see "new" objects. Thoughts? brgds, H-P