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/...

[Warner Losh]

From: Dimitry Andric <dim at 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