linux-kernel - Re: [x86 setup 13/33] Header file to produce 16-bit code with gcc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/