From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azsXI-0002Yh-8V for qemu-devel@nongnu.org; Mon, 09 May 2016 17:16:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1azsXB-0002pm-GX for qemu-devel@nongnu.org; Mon, 09 May 2016 17:16:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56131) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azsXB-0002pJ-AN for qemu-devel@nongnu.org; Mon, 09 May 2016 17:16:09 -0400 References: <1461600281-23048-1-git-send-email-rjones@redhat.com> <20160509132449.GF3372@stefanha-x1.localdomain> <20160509164814.GS1683@redhat.com> From: Laszlo Ersek Message-ID: <62d1c78f-b216-bdc0-54df-97bca92962ca@redhat.com> Date: Mon, 9 May 2016 23:16:00 +0200 MIME-Version: 1.0 In-Reply-To: <20160509164814.GS1683@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v6] Add optionrom compatible with fw_cfg DMA version List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" , Stefan Hajnoczi Cc: qemu-devel , =?UTF-8?Q?Marc_Mar=c3=ad?= , Eduardo Habkost , "Michael S. Tsirkin" , Gerd Hoffmann , Stefan Hajnoczi , Paolo Bonzini , Richard Henderson On 05/09/16 18:48, Richard W.M. Jones wrote: > > Actually there's a rather more fundamental problem. In the current > linuxboot_dma.c we use asm statements at the top and bottom of the > file (outside any function). The asm statements define the header and > what I assume is the footer of the file. At any rate, they encode the > size of the file (the calculation `.byte (_end - _start) / 512'). > > Clang just rearranges everything in the file, so the _start and _end > asm snippets appear together at the beginning of the input to the > assembler, and nothing works after that. > > So that pretty much screws up the whole project of trying to write an > option ROM in C. > > Of course we're well outside any standards here. Can we tell clang > users to use the GCC/pre-compiled option ROMs :-? Any other ideas? I > don't think I've missed a flag (GCC has -fno-toplevel-reorder, but > clang 3.8 doesn't ...) IIRC for a while we used to ship pre-compiled ACPI byte-code, for people who didn't have "iasl" installed. We could make this C source file gcc-only, and provide a pre-compiled assembly source file for those platforms that only have clang. Laszlo