From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOkER-00036E-TS for qemu-devel@nongnu.org; Thu, 28 Jan 2016 05:55:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aOkEM-0005JE-0P for qemu-devel@nongnu.org; Thu, 28 Jan 2016 05:55:19 -0500 Received: from mail-wm0-x241.google.com ([2a00:1450:400c:c09::241]:33267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOkEL-0005Ix-LW for qemu-devel@nongnu.org; Thu, 28 Jan 2016 05:55:13 -0500 Received: by mail-wm0-x241.google.com with SMTP id r129so2934263wmr.0 for ; Thu, 28 Jan 2016 02:55:13 -0800 (PST) Date: Thu, 28 Jan 2016 10:55:10 +0000 From: Stefan Hajnoczi Message-ID: <20160128105510.GC7206@stefanha-x1.localdomain> References: <1453727868-11147-1-git-send-email-markmb@redhat.com> <20160126111154.GA14533@stefanha-x1.localdomain> <20160126122004.0798fd71@markmb_rh> <1453807572.24277.22.camel@redhat.com> <20160127164329.GO26163@stefanha-x1.localdomain> <20160127175728.41b256a4@markmb_rh> <20160127171727.GA7850@morn.lan> <20160128111807.07fd682b@markmb_rh> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eHhjakXzOLJAF9wJ" Content-Disposition: inline In-Reply-To: <20160128111807.07fd682b@markmb_rh> Subject: Re: [Qemu-devel] [PATCH v3] Add optionrom compatible with fw_cfg DMA version List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marc =?iso-8859-1?Q?Mar=ED?= Cc: "Gabriel L. Somlo" , qemu-devel@nongnu.org, Kevin O'Connor , Gerd Hoffmann , Stefan Hajnoczi , Paolo Bonzini , Laszlo --eHhjakXzOLJAF9wJ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 28, 2016 at 11:18:07AM +0100, Marc Mar=ED wrote: > On Wed, 27 Jan 2016 12:17:27 -0500 > "Kevin O'Connor" wrote: >=20 > > On Wed, Jan 27, 2016 at 05:57:28PM +0100, Marc Mar=ED wrote: > > > On Wed, 27 Jan 2016 16:43:29 +0000 > > > Stefan Hajnoczi wrote: > > > =20 > > > > On Tue, Jan 26, 2016 at 12:26:12PM +0100, Gerd Hoffmann wrote: =20 > > > > > On Di, 2016-01-26 at 12:20 +0100, Marc Mar=ED wrote: =20 > > > > > > On Tue, 26 Jan 2016 11:11:54 +0000 > > > > > > Stefan Hajnoczi wrote: > > > > > > =20 > > > > > > > On Mon, Jan 25, 2016 at 02:17:48PM +0100, Marc Mar=ED > > > > > > > wrote: =20 > > > > > > > > +linuxboot_dma.img: linuxboot_dma.o > > > > > > > > + $(call quiet-command,$(LD) $(LDFLAGS_NOPIE) -m > > > > > > > > elf_i386 -Ttext 0 -e _start -s -o $@ $<," Building > > > > > > > > $(TARGET_DIR)$@") + %.img: %.o > > > > > > > > $(call quiet-command,$(LD) $(LDFLAGS_NOPIE) > > > > > > > > -Ttext 0 -e _start -s -o $@ $<," Building > > > > > > > > $(TARGET_DIR)$@") =20 > > > > > > >=20 > > > > > > > Why is -m elf_i386 necessary for linuxboot_dma.img but not > > > > > > > for the other *.img files? =20 > > > > > >=20 > > > > > > I cannot give a precise explanation. But if I don't force an > > > > > > output type, I get this error: > > > > > >=20 > > > > > > Building optionrom/linuxboot_dma.img > > > > > > ld: i386 architecture of input file `linuxboot_dma.o' is > > > > > > incompatible with i386:x86-64 output =20 > > > > >=20 > > > > > Any chance the linker needs -m32 too? =20 > > > >=20 > > > > I wonder why this isn't a problem for the existing firmware > > > > code. Are we really building x86_64 ELF files for our firmware? = =20 > > >=20 > > > Yes they are x86_64: > > >=20 > > > pc-bios/optionrom/linuxboot.img: ELF 64-bit LSB executable, x86-64, > > > version 1 (SYSV), statically linked, stripped > > >=20 > > > But as they are written directly in assembly, it does not give any > > > problem. Whereas when mixing C and ASM, it does give problems. =20 > >=20 > > Would it hurt anything to add "-m elf_i386" to the generic assembler > > rule and then use that for both targets? (Just to keep the makefile a > > little simpler.) >=20 > It doesn't seem to hurt, and it is simpler. Great, I think this makes sense. Stefan --eHhjakXzOLJAF9wJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWqfOOAAoJEJykq7OBq3PIWz4H/j/On00dTP/aaRnMuOd3YxE4 hSlMPfwzgn6hEdgKnjY6Hc3U/dAton36QGQzb2Yk7A2OdDkkYu+Eg+DPT+0vS1TH rFftWLOoAcFqxXTUAjWlcseag4bHC0kEPElbtTKEQiZhR6G4wdnYwec7udcGbN91 9hXLIcSBSlKFIOjTTE5TJJIRj3/XXaB25CRv6LVdQcWV5P8Hhjj0QXczkK6NYSln jTAbGzPNpcvvhCpaDazSHXhD9Ojhq8gUzkp+QTMlGb09rAFvMVnnLkcLupuKWzIM dnNFu2c9hRe0wXUJETIoTV/rjyKrbFS4/bW/7FvGKOAI0rm4ja+Ga1CgDm9+BCo= =FJHM -----END PGP SIGNATURE----- --eHhjakXzOLJAF9wJ--