From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32255 invoked by alias); 10 May 2011 16:28:01 -0000 Received: (qmail 32192 invoked by uid 22791); 10 May 2011 16:27:58 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_BJ,TW_JC,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 May 2011 16:27:42 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p4AGRe3e016876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 May 2011 12:27:40 -0400 Received: from [10.36.10.166] (vpn2-10-166.ams2.redhat.com [10.36.10.166]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p4AGRdq7013054; Tue, 10 May 2011 12:27:40 -0400 Message-ID: <4DC967BE.2020201@redhat.com> Date: Tue, 10 May 2011 16:28:00 -0000 From: Nick Clifton User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jan Beulich CC: binutils@sourceware.org Subject: Re: ld's targets vs emulations (intending to link EFI binaries on Linux) References: <4DBE7CE2020000780003F1C6@vpn.id2.novell.com> In-Reply-To: <4DBE7CE2020000780003F1C6@vpn.id2.novell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-05/txt/msg00118.txt.bz2 Hi Jan, > What is the point of ld supporting (in e.g. the default x86 Linux > configurations) PE executables as targets, but not as emulations? > This basically means that one can link such executables, but there's > no control over the various linking parameters (as those are > processed by the respective [not present] emulation code). Essentially this is because it is easier this way. Supporting multiple, dissimilar emulations would make the linker a lot more complex. Changing the output format is actually a problematic feature of the linker, and one that is disabled for some architectures. It is much cleaner to link without changing format and then use objcopy to convert the resulting binary. You are correct however in saying that objcopy will not convert relocations and this is actually one of the big problems with format conversions - there is rarely a good mapping between the relocations of the formats. Cheers Nick