From owner-svn-src-projects@FreeBSD.ORG Tue Dec 7 19:40:44 2010 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23016106566C; Tue, 7 Dec 2010 19:40:44 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay009.isp.belgacom.be (mailrelay009.isp.belgacom.be [195.238.6.176]) by mx1.freebsd.org (Postfix) with ESMTP id 5064C8FC1F; Tue, 7 Dec 2010 19:40:42 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPca/kxbscFI/2dsb2JhbACjRHLCDoVJBA Received: from 72.193-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.193.72]) by relay.skynet.be with ESMTP; 07 Dec 2010 20:40:41 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.4/8.14.4) with ESMTP id oB7JeeiZ005257; Tue, 7 Dec 2010 20:40:40 +0100 (CET) (envelope-from tijl@freebsd.org) From: Tijl Coosemans To: Dimitry Andric Date: Tue, 7 Dec 2010 20:40:20 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.5.2; i386; ; ) References: <201012052024.oB5KOMUF007051@svn.freebsd.org> <4CFD2E01.1000509@FreeBSD.org> <201012071448.47319.tijl@freebsd.org> In-Reply-To: <201012071448.47319.tijl@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1608532.rUQiOJzNNZ"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201012072040.38364.tijl@freebsd.org> Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org, Anton Shterenlikht 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/... X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 19:40:44 -0000 --nextPart1608532.rUQiOJzNNZ Content-Type: multipart/mixed; boundary="Boundary-01=_l2o/MsFYTpj6+af" Content-Transfer-Encoding: 7bit --Boundary-01=_l2o/MsFYTpj6+af Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 07 December 2010 14:48:41 Tijl Coosemans wrote: > 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, s= o 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, mip= s and >>>> powerpc. >> ... >>> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> I am completely open for both approaches, really, and would like to see >> a bit of consensus. >>=20 >> 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. >>=20 >> 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. >>=20 >> So, which colour? :) >=20 > A third alternative :) Stop setting OSABI. >=20 > 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. >=20 > 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. I worked out a small patch to fix branding on ia64. Please give it a try. The patch links crtbrand.c in crti.o. On other architectures crtbrand.c is included from crt1.c, but that's not a C source code file on ia64. It is linked in crti rather than all the crt1 variants because the original commit log for crtbrand.c mentions that was the intention. --Boundary-01=_l2o/MsFYTpj6+af Content-Type: text/x-patch; charset="us-ascii"; name="ia64.abitag.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ia64.abitag.diff" diff --git a/lib/csu/ia64/Makefile b/lib/csu/ia64/Makefile index 781c458..12bfb09 100644 =2D-- a/lib/csu/ia64/Makefile +++ b/lib/csu/ia64/Makefile @@ -5,8 +5,6 @@ SRCS=3D crt1.S crti.S crtn.S OBJS=3D ${SRCS:N*.h:R:S/$/.o/g} OBJS+=3D Scrt1.o gcrt1.o =2DCFLAGS+=3D -I${.CURDIR}/../common \ =2D -I${.CURDIR}/../../libc/include =20 all: ${OBJS} =20 @@ -18,6 +16,9 @@ gcrt1.o: crt1.S Scrt1.o: crt1.S ${CC} ${CFLAGS} -fPIC -DPIC -c -o Scrt1.o ${.ALLSRC} =20 +crti.o: crtbrand.c + ${CC} ${CFLAGS} -o crti.o -nostdlib -Wl,-r ${.ALLSRC} + realinstall: ${INSTALL} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ ${OBJS} ${DESTDIR}${LIBDIR} --Boundary-01=_l2o/MsFYTpj6+af-- --nextPart1608532.rUQiOJzNNZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iF4EABEIAAYFAkz+jbYACgkQfoCS2CCgtiu2JwD/SCyvLbKYBTObWTtXmGMoLJlG pidm4uKd914qa/d9ei4A/02Z8PxQUowqqgdm/3oNzjoit+e13wsDVZHDI1C9qFAS =Cqxz -----END PGP SIGNATURE----- --nextPart1608532.rUQiOJzNNZ--