Date: Tue, 07 May 2002 12:18:31 -0400 From: Nathan Hawkins <utsl@quic.net> To: John Baldwin <jhb@FreeBSD.org> Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <3CD7FE57.1000508@quic.net> References: <XFMail.20020507103320.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CD7FE57.1000508>