From owner-freebsd-arch Tue May 7 9:18:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from trantor.utsl.org (cvg-65-27-234-192.cinci.rr.com [65.27.234.192]) by hub.freebsd.org (Postfix) with ESMTP id 1A9F537B409; Tue, 7 May 2002 09:18:33 -0700 (PDT) Received: from hotrod.utsl.org ([10.10.57.3] helo=quic.net) by trantor.utsl.org with esmtp (Exim 3.35 #1 (Debian)) id 1757fb-0000yv-00; Tue, 07 May 2002 12:18:31 -0400 Message-ID: <3CD7FE57.1000508@quic.net> Date: Tue, 07 May 2002 12:18:31 -0400 From: Nathan Hawkins User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020502 Debian/1.0rc1-3 MIME-Version: 1.0 To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. References: X-Enigmail-Version: 0.49.5.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin wrote: >Right. I would like to use the ELF_ABI_OSVERSION thingie, but according to >O'Brien it violates the ELF spec to use any value other than 0. But then >why does it exist if we can't use it? :( One idea being thrown about is >that for the new ABI (It would be FreeBSD ABI 2) there would be a syscall >at syscall 0 that would never change that could be used to select what "minor" >version of the ABI you wanted to use, so if we wanted to add a new ABI at >some point in the future we could stick that syscall in crt.c (or whatever >the proper startup file is) to change to ABI 2.1 or 2.2 or something. However, >for the current change, I think bumping the ELF OS version and adding a new >ABI front-end for ABI 2 is the way to go. > > I'd like to see FreeBSD start using ELF .note.ABI-tag sections to handle the binary OS type/versioning. I know that at least NetBSD, Linux and Hurd do it this way, and I think most others do too. It looks like gcc is already inserting them, (run readelf -S, and you should see it) so it'd be a matter of adding to the binary emulation selector to check .note.ABI-tag. For your new ABI, set a version number in the tag. I believe the tag gcc is putting in already has a field for that. This also has the benefit of making emulations work more transparently, as it should obsolete brandelf. >Another advantage of this is that if our tools handle the OS version bit >properly, we can actually not have to worry about much of a flag day. Instead >we can gradually add the new ABI and support for it and then just quietly >throw the switch to change the default ABI in current one day. Old binaries >would still run fine. The only tricky part is for libc.so since you would >really need two version of it (unless we also bumped to libc.so.6 for this..) >and we would need to make sure we linked to the right OSVERSION of the lib when >doing runtime linking, whcih could get ugly. > This would be about the same for the above suggestion. I think bumping libc version would be good. It solves things neatly. ---Nathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message