This is a gratuitous GCC-ism. For C code actually compiled with GCC we should be using -m16 where it's available (GCC 4.9+).
And where the only thing marked with .code16gcc is explicit assembler code, we should just use .code16 and avoid letting the compiler make any of the assumptions that the difference affects. Which, in fact, we already do.
(Once upon a time with ancient versions of gas, we needed to use .code16gcc because some instructions just wouldn't compile otherwise. That hasn't been true for a while though.)
It still doesn't actually build with clang after this, but it's a bit closer.
GCC 4.9 and clang 3.5 support the -m16 option on the command line which supersedes the hackish ".code16gcc" assembler directive. Use it where possible.
Signed-off-by: David Woodhouse David.Woodhouse@intel.com --- Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile index 78b598e..4c42124 100644 --- a/Makefile +++ b/Makefile @@ -62,13 +62,15 @@ COMMONCFLAGS := -I$(OUT) -Isrc -Os -MD -g \ COMMONCFLAGS += $(call cc-option,$(CC),-nopie,) COMMONCFLAGS += $(call cc-option,$(CC),-fno-stack-protector,) COMMONCFLAGS += $(call cc-option,$(CC),-fno-stack-protector-all,) +COMMA := ,
CFLAGS32FLAT := $(COMMONCFLAGS) -DMODE16=0 -DMODESEGMENT=0 -fomit-frame-pointer CFLAGSSEG := $(COMMONCFLAGS) -DMODESEGMENT=1 -fno-defer-pop \ $(call cc-option,$(CC),-fno-jump-tables,-DMANUAL_NO_JUMP_TABLE) \ $(call cc-option,$(CC),-fno-tree-switch-conversion,) CFLAGS32SEG := $(CFLAGSSEG) -DMODE16=0 -fomit-frame-pointer -CFLAGS16INC := $(CFLAGSSEG) -DMODE16=1 -Wa,src/code16gcc.s \ +CFLAGS16INC := $(CFLAGSSEG) -DMODE16=1 \ + $(call cc-option,$(CC),-m16,-Wa$(COMMA)src/code16gcc.s) \ $(call cc-option,$(CC),--param large-stack-frame=4,-fno-inline) CFLAGS16 := $(CFLAGS16INC) -fomit-frame-pointer
There's no need to use .code16gcc where we are writing assembler code explicitly. It only affects word-size-ambiguous instructions, and we should just be explicit. And we are.
Signed-off-by: David Woodhouse David.Woodhouse@intel.com --- src/fw/smm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/fw/smm.c b/src/fw/smm.c index 0f59f20..77e1e63 100644 --- a/src/fw/smm.c +++ b/src/fw/smm.c @@ -19,7 +19,7 @@ extern u8 smm_relocation_start, smm_relocation_end; ASM32FLAT( ".global smm_relocation_start, smm_relocation_end\n" - " .code16gcc\n" + " .code16\n"
/* code to relocate SMBASE to 0xa0000 */ "smm_relocation_start:\n" @@ -46,7 +46,7 @@ ASM32FLAT( extern u8 smm_code_start, smm_code_end; ASM32FLAT( ".global smm_code_start, smm_code_end\n" - " .code16gcc\n" + " .code16\n" "smm_code_start:\n" " rsm\n" "smm_code_end:\n"
There's no need to use .code16gcc where we are writing assembler code explicitly. It only affects word-size-ambiguous instructions, and we should just be explicit. And we are.
Signed-off-by: David Woodhouse David.Woodhouse@intel.com --- src/romlayout.S | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/romlayout.S b/src/romlayout.S index 57e8bcc..9c2719e 100644 --- a/src/romlayout.S +++ b/src/romlayout.S @@ -21,7 +21,7 @@ // %edx = return location (in 32bit mode) // Clobbers: ecx, flags, segment registers, cr0, idt/gdt DECLFUNC transition32 - .code16gcc + .code16 transition32: movl %eax, %ecx
@@ -102,7 +102,7 @@ transition16big:
ljmpw $SEG32_MODE16BIG_CS, $1f
- .code16gcc + .code16 1: // Disable protected mode movl %cr0, %eax @@ -145,7 +145,7 @@ __call16big: jmp transition16big
// Make call. - .code16gcc + .code16 1: movl $_zonelow_seg, %edx // Adjust %ds, %ss, and %esp movl %edx, %ds movzwl StackSeg, %edx @@ -177,7 +177,7 @@ __call16big: // Far call a 16bit function from 16bit mode with a specified cpu register state // %eax = address of struct bregs, %edx = segment of struct bregs // Clobbers: %e[bc]x, %e[ds]i, flags - .code16gcc + .code16 DECLFUNC __farcall16 __farcall16: // Save %edx/%eax, %ebp @@ -372,7 +372,7 @@ entry_pcibios32: popfl lretl
- .code16gcc + .code16 DECLFUNC entry_pcibios16 entry_pcibios16: ENTRY_ARG handle_pcibios @@ -421,7 +421,7 @@ entry_elf: movl $BUILD_STACK_ADDR, %esp ljmpl $SEG32_MODE32_CS, $_cfunc32flat_handle_post
- .code16gcc + .code16
// UEFI Compatibility Support Module (CSM) entry point EXPORTFUNC entry_csm @@ -453,7 +453,7 @@ entry_csm: __csm_return: movl $1f, %edx jmp transition16big - .code16gcc + .code16
// Switch back to original stack 1: movzwl BREGS_code+2(%eax), %edx
There's no need to use .code16gcc where we are writing assembler code explicitly. It only affects word-size-ambiguous instructions, and we should just be explicit. And we are.
Signed-off-by: David Woodhouse David.Woodhouse@intel.com --- vgasrc/vgaentry.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/vgasrc/vgaentry.S b/vgasrc/vgaentry.S index 11197f1..3c2c885 100644 --- a/vgasrc/vgaentry.S +++ b/vgasrc/vgaentry.S @@ -15,7 +15,7 @@ ****************************************************************/
.section .rom.header - .code16gcc + .code16 .global _rom_header, _rom_header_size, _rom_header_checksum _rom_header: .word 0xaa55
On Tue, Jun 03, 2014 at 05:25:57PM +0100, David Woodhouse wrote:
This is a gratuitous GCC-ism. For C code actually compiled with GCC we should be using -m16 where it's available (GCC 4.9+).
And where the only thing marked with .code16gcc is explicit assembler code, we should just use .code16 and avoid letting the compiler make any of the assumptions that the difference affects. Which, in fact, we already do.
(Once upon a time with ancient versions of gas, we needed to use .code16gcc because some instructions just wouldn't compile otherwise. That hasn't been true for a while though.)
It still doesn't actually build with clang after this, but it's a bit closer.
Thanks. Looks good to me.
I updated the series to apply on top of my pending patches and added it to my queue:
https://github.com/KevinOConnor/seabios/commits/testing
-Kevin
On Tue, Jun 03, 2014 at 03:58:50PM -0400, Kevin O'Connor wrote:
On Tue, Jun 03, 2014 at 05:25:57PM +0100, David Woodhouse wrote:
This is a gratuitous GCC-ism. For C code actually compiled with GCC we should be using -m16 where it's available (GCC 4.9+).
And where the only thing marked with .code16gcc is explicit assembler code, we should just use .code16 and avoid letting the compiler make any of the assumptions that the difference affects. Which, in fact, we already do.
(Once upon a time with ancient versions of gas, we needed to use .code16gcc because some instructions just wouldn't compile otherwise. That hasn't been true for a while though.)
It still doesn't actually build with clang after this, but it's a bit closer.
Thanks. Looks good to me.
I updated the series to apply on top of my pending patches and added it to my queue:
FYI, I committed this (slightly modified) patch series.
-Kevin
-
David Woodhouse -
Kevin O'Connor