Date: Tue, 07 Dec 2010 06:39:36 -0700 (MST) From: Warner Losh <imp@bsdimp.com> To: dim@FreeBSD.org Cc: svn-src-projects@FreeBSD.org, tijl@coosemans.org, src-committers@FreeBSD.org Subject: Re: svn commit: r216200 - in projects/binutils-2.17: contrib/binutils/bfd contrib/binutils/gas/config contrib/binutils/ld/emulparams gnu/usr.bin/binutils/libbfd sys/boot/ia64/efi sys/boot/ia64/ski sys/... Message-ID: <20101207.063936.74702962.imp@bsdimp.com> In-Reply-To: <4CFD2E01.1000509@FreeBSD.org> References: <201012052024.oB5KOMUF007051@svn.freebsd.org> <201012061718.13823.tijl@coosemans.org> <4CFD2E01.1000509@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Dimitry Andric <dim@freebsd.org> Subject: Re: svn commit: r216200 - in projects/binutils-2.17: contrib/binutils/bfd contrib/binutils/gas/config contrib/binutils/ld/emulparams gnu/usr.bin/binutils/libbfd sys/boot/ia64/efi sys/boot/ia64/ski sys/... Date: Mon, 06 Dec 2010 19:40:01 +0100 > On 2010-12-06 17:18, Tijl Coosemans wrote: > > On Sunday 05 December 2010 21:24:22 Dimitry Andric wrote: > ... > >> For ia64, add a proper 'elf64-ia64-freebsd' output format to BFD, so the > >> ELF branding for FreeBSD is done in the same way as amd64, i386 and > >> sparc. Something similar should probably also be done for arm, mips and > >> powerpc. > ... > > Does this change fix the problem described here? > > http://lists.freebsd.org/pipermail/freebsd-ia64/2010-November/002773.html > > That problem is most likely due to using the binutils 2.20.1 port, which > does not have support for a FreeBSD/ia64 target. I posted a similar > patch for binutils 2.20 (without any base system modifications) here: > > http://lists.freebsd.org/pipermail/freebsd-current/2010-December/021649.html > > > > About elf64-ia64-freebsd, I'm not sure it is needed. FreeBSD 4.0 and > > older used non-standard ELF branding and that format got the name > > elf32-i386-freebsd (and elf64-alpha-freebsd). Later versions of FreeBSD > > use the standard method, but keep calling it elf32-i386-freebsd. > > The problem is that BFD needs to set the ELF_OSABI field in the ELF > header to ELFOSABI_FREEBSD, at least for FreeBSD targets (whereas Linux > does not care about the ELF_OSABI field at all, it seems). > > Because BFD sets the ELF_OSABI field to ELFOSABI_SYSV by default, this > can only be done properly by selecting a specific BFD target > ("elf64-ia64-freebsd") which is different from the default, usually > "elf64-ia64-little". The same principle applies to other arches. > > In our base binutils, there is a hack in contrib/binutils/bfd/elf.c > (function prep_headers(), line 4325) to set that field unconditionally, > but obviously this is not in upstream binutils, as it would most likely > be unacceptable for them. (Just maybe, if it was put between #ifdef > __FreeBSD__ guards, but still unlikely. :) > > (Note that due to this elf.c hack, the messing with elf-fbsd-brand.c in > gnu/usr.bin/binutils/libbfd/Makefile.{amd64,ia64} is actually completely > unnecessary...) > > > > Rather than copying this practise to other architectures, maybe > > binutils should be fixed for i386. It isn't used on amd64 and sparc64 > > either as far as I can tell. > > It is, in the binutils-2.17 branch, which has . :) The question is if > we want to propagate our elf.c hack forever, in which case it would > have to be added to the binutils port. > > The alternative, adding FreeBSD-specific targets, is more likely to be > accepted by the binutils maintainers, which would be nice if we want to > be able to build with "stock" binutils on FreeBSD. > > I am completely open for both approaches, really, and would like to see > a bit of consensus. > > The "just hack elf.c" approach causes less churn in the tree, because it > is small, and saves modifying a few places in the tree where target > names are used, such as kernel link scripts. There is no way to specify > a "non-FreeBSD" target, though. > > The "add FreeBSD targets" approach causes a bit of churn, but if we > submit the required changes to binutils upstream, they are more likely > to be accepted, as they are fairly minimal, and don't disturb support > for other platforms. There will also be the possibility to produce > non-FreeBSD-branded ELF files, although I am not sure if that is used > very often. I'd add the FreeBSD targets... We have a bunch of them already, and their lack is a problem relative to linux, which has linux specific targets for ages... Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101207.063936.74702962.imp>