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

[Tijl Coosemans]

On Monday 06 December 2010 19:40:01 Dimitry Andric wrote:
> 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.
> ...
>> 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.

I see. I thought target specifics were set at compile time, but
apparently BFD can target multiple formats at runtime.

>> 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.
> 
> So, which colour? :)

A third alternative :) Stop setting OSABI.

Looking at the binutils 2.20.1 BFD source the only files in which OSABI
is set to FreeBSD are: elf32-i386.c, elf64-alpha.c, elf64-sparc.c and
elf64-x86-64.c. For those architectures FreeBSD is the only OS that sets
OSABI. Since nobody cares about it maybe FreeBSD shouldn't either. The
field is redundant anyway given the .note.ABI-tag section.

I noticed the .note.ABI-tag section was missing from the ia64 startup
code (src/lib/csu/ia64/crt1.S). Adding it should fix the branding
problem reported on the mailing lists too and then there's no need for
hacks or special *-freebsd ELF formats.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/svn-src-projects/attachments/20101207/3599b24f/attachment.pgp