[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4693AA56.9040109@zytor.com>
Date: Tue, 10 Jul 2007 08:48:38 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Andi Kleen <ak@...e.de>
CC: Segher Boessenkool <segher@...nel.crashing.org>,
linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
akpm@...ux-foundation.org
Subject: Re: [x86 setup 13/33] Header file to produce 16-bit code with gcc
Andi Kleen wrote:
> On Tuesday 10 July 2007 16:16:29 Segher Boessenkool wrote:
>>> gcc for i386 can be used with the assembly prefix ".code16gcc" to
>>> generate
>>> 16-bit (real-mode) code. This header file provides the assembly
>>> prefix.
>> This only works correctly with newer GCCs if you pass the
>> -fno-toplevel-reorder option (and it only works on older
>> GCC versions by accident).
>
> And on older ones (gcc-3.3-hammer / 3.4 / 4.0 ) -fno-unit-at-a-time
>
> Still it seems quite fragile to me agreed.
The alternative, of course, is to compile to an .s file and insert
.code16gcc into the .s file. This makes the Makefile uglier, but would
be more resilient against oddball gcc changes.
I'm a bit surprised about the claim w.r.t. -fno-unit-at-a-time (although
I guess that is the default and one would thus typically not see this.)
Got any pointers why that would cause a global asm() to be scrambled
around?
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists