From: "Marc Marí" <markmb@redhat.com>
To: Kevin O'Connor <kevin@koconnor.net>
Cc: "Gabriel L. Somlo" <somlo@cmu.edu>,
qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>, Laszlo <lersek@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3] Add optionrom compatible with fw_cfg DMA version
Date: Thu, 28 Jan 2016 11:18:07 +0100 [thread overview]
Message-ID: <20160128111807.07fd682b@markmb_rh> (raw)
In-Reply-To: <20160127171727.GA7850@morn.lan>
On Wed, 27 Jan 2016 12:17:27 -0500
"Kevin O'Connor" <kevin@koconnor.net> wrote:
> On Wed, Jan 27, 2016 at 05:57:28PM +0100, Marc Marí wrote:
> > On Wed, 27 Jan 2016 16:43:29 +0000
> > Stefan Hajnoczi <stefanha@redhat.com> wrote:
> >
> > > On Tue, Jan 26, 2016 at 12:26:12PM +0100, Gerd Hoffmann wrote:
> > > > On Di, 2016-01-26 at 12:20 +0100, Marc Marí wrote:
> > > > > On Tue, 26 Jan 2016 11:11:54 +0000
> > > > > Stefan Hajnoczi <stefanha@redhat.com> wrote:
> > > > >
> > > > > > On Mon, Jan 25, 2016 at 02:17:48PM +0100, Marc Marí
> > > > > > wrote:
> > > > > > > +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)$@")
> > > > > >
> > > > > > Why is -m elf_i386 necessary for linuxboot_dma.img but not
> > > > > > for the other *.img files?
> > > > >
> > > > > I cannot give a precise explanation. But if I don't force an
> > > > > output type, I get this error:
> > > > >
> > > > > Building optionrom/linuxboot_dma.img
> > > > > ld: i386 architecture of input file `linuxboot_dma.o' is
> > > > > incompatible with i386:x86-64 output
> > > >
> > > > Any chance the linker needs -m32 too?
> > >
> > > I wonder why this isn't a problem for the existing firmware
> > > code. Are we really building x86_64 ELF files for our firmware?
> >
> > Yes they are x86_64:
> >
> > pc-bios/optionrom/linuxboot.img: ELF 64-bit LSB executable, x86-64,
> > version 1 (SYSV), statically linked, stripped
> >
> > But as they are written directly in assembly, it does not give any
> > problem. Whereas when mixing C and ASM, it does give problems.
>
> 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.)
It doesn't seem to hurt, and it is simpler.
Marc
next prev parent reply other threads:[~2016-01-28 10:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-25 13:17 [Qemu-devel] [PATCH v3] Add optionrom compatible with fw_cfg DMA version Marc Marí
2016-01-26 11:11 ` Stefan Hajnoczi
2016-01-26 11:20 ` Marc Marí
2016-01-26 11:26 ` Gerd Hoffmann
2016-01-27 16:43 ` Stefan Hajnoczi
2016-01-27 16:57 ` Marc Marí
2016-01-27 17:17 ` Kevin O'Connor
2016-01-28 10:18 ` Marc Marí [this message]
2016-01-28 10:55 ` Stefan Hajnoczi
2016-01-28 0:14 ` Kevin O'Connor
2016-01-28 11:20 ` Marc Marí
2016-01-28 15:24 ` Kevin O'Connor
2016-01-28 21:06 ` Marc Marí
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160128111807.07fd682b@markmb_rh \
--to=markmb@redhat.com \
--cc=kevin@koconnor.net \
--cc=kraxel@redhat.com \
--cc=lersek@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=somlo@cmu.edu \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).