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 23:08:33 +0200
From:	"Pawel Dziepak" <hryssta@...il.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"Segher Boessenkool" <segher@...nel.crashing.org>,
	"Andi Kleen" <ak@...e.de>, 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

On 7/10/07, Segher Boessenkool <segher@...nel.crashing.org> wrote:
> > 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.
>
> This would be even more fragile.  The exact format of GCC's
> assembler code output isn't defined at all, so in principle
> this is a hopeless task.  In practice just putting the
> .code16gcc directive on the first line would likely work
> though, GCC never generates a .code32 AFAIK, but it isn't
> guaranteed that this will work (or will keep working).

Unfortunately, .code16gcc is still experimental (at least binutils'
website says that). What is worse, it says that it is possible that
16bit code produced on GCC won't work on pre-80386 processors (before
switching to protected mode you have to think about cpu as a
pre-80386).

I don't think that -m16 flag will be introduced quickly. In fact, only
OS developers _sometimes_ use 16 bit code...

I did a fast test and now I know that assembler instructions are
almost ignored by GCC and passed to gas. The situation is the same
with .code16gcc, what mean that gas has to translate 32bit code from
GCC to 16 bit code. The result binary was correct 16 bit program (at
least its code looked good), but it is IMHO too many translations from
C to 32bit assembler and then to 16bit assembler, that can cause
unpredictable errors.

Additionally, I prefer to write architecture depend procedures in
assembler (but is only *my* opinion, and you probably disagree).
Assembler is faster, you have bigger control over the code, and
portability of C is in this circumstances not necessary.

Pawel
-
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/