[SOLVED] Is this a Bug in NASM?

Alex · **Joined:** Sun Jan 18, 2009 2:12 am **Posts:** 16

Hi folks

I think i found a Bug in NASM.
The NASM version is 2.09.10 compiled on Oct 17 2011.
It would be nice if someone could see if this bug is still present in a newer version of NASM.
The code thet should create an error is this:

Code:

cpu 8086
bits 16

segment .text progbits alloc exec nowrite align=1

;== Code =======================================================================
segment .text

                mov     ax, fs

I assambled it with this comand:
nasm -f elf -o Test.o -l Test_nasm.info Test.asm

The thing is that the FS register does not exist in the Intel 8086 CPU, or am i wrong?

Cheers, Alex

Bender · **Posted:** Sun Apr 20, 2014 3:25 am

I may be wrong but NASM should default to 32-bit (i386) while using ELF, and 64-bit while using ELF64. Compile it to binary and see if it works.

Alex · **Joined:** Sun Jan 18, 2009 2:12 am **Posts:** 16

Hmmmm
I changed the code to this:

Code:

cpu 8086
bits 16

segment .text progbits align=1

;== Code =======================================================================
segment .text

                mov     ax, fs

And assambled it with this command:
nasm -f bin -o Test.bin -l Test_nasm.info Test.asm

It is now a plane binary file, but it is still assambling without error.

alexfru · **Joined:** Tue Mar 04, 2014 5:27 am **Posts:** 1108

Alex wrote:

The thing is that the FS register does not exist in the Intel 8086 CPU, or am i wrong?

Did you check NASM documentation w.r.t. CPUs, CPU modes and file formats?

alexfru · **Joined:** Tue Mar 04, 2014 5:27 am **Posts:** 1108

Bender wrote:

I may be wrong but NASM should default to 32-bit (i386) while using ELF, and 64-bit while using ELF64. Compile it to binary and see if it works.

You can use also "bits 16" with "-f elf". You'll get 16-bit relocation records (R_386_16 and R_386_PC16) instead of 32-bit ones (R_386_32 and R_386_PC32). So, technically, given a linker that supports these "extended" records (ld should), you can use NASM and that linker and ELF object files to assemble and link 16-bit code for the tiny (everything's in one segment) and small (code and all data are in two different segments) memory models.

Alex · **Joined:** Sun Jan 18, 2009 2:12 am **Posts:** 16

Now the documentation of NASM says:

Quote:

6.8 CPU: Defining CPU Dependencies
The CPU directive restricts assembly to those instructions which are available on the specified CPU.
Options are:
• CPU 8086 Assemble only 8086 instruction set
• CPU 186 Assemble instructions up to the 80186 instruction set
• CPU 286 Assemble instructions up to the 286 instruction set
• CPU 386 Assemble instructions up to the 386 instruction set
• CPU 486 486 instruction set
• CPU 586 Pentium instruction set
• CPU PENTIUM Same as 586
• CPU 686 P6 instruction set
• CPU PPRO Same as 686
• CPU P2 Same as 686
• CPU P3 Pentium III (Katmai) instruction sets
• CPU KATMAI Same as P3
• CPU P4 Pentium 4 (Willamette) instruction set
• CPU WILLAMETTE Same as P4
• CPU PRESCOTT Prescott instruction set
• CPU X64 x86−64 (x64/AMD64/Intel 64) instruction set
• CPU IA64 IA64 CPU (in x86 mode) instruction set
All options are case insensitive. All instructions will be selected only if they apply to the selected CPU or
lower. By default, all instructions are available.

I may be wrong but i dont think that the fileformat should change something

Alex · **Joined:** Sun Jan 18, 2009 2:12 am **Posts:** 16

@alexfru Exactly

I am using this option

Alex · **Joined:** Sun Jan 18, 2009 2:12 am **Posts:** 16

Yep, i am using "ld" to link my prog

iansjack · **Posted:** Sun Apr 20, 2014 4:10 am

It's a known NASM bug: http://sourceforge.net/p/nasm/bugs/180/

Moral - don't rely upon the assembler/compiler to do your bug checking for you.

Alex · **Joined:** Sun Jan 18, 2009 2:12 am **Posts:** 16

Ok

so it is a known bug and no wone fixed it

iansjack · **Posted:** Sun Apr 20, 2014 4:20 am

Correct. If it bothers you enough, join the NASM development team and fix the bug. Or ask for your money back.

Alex · **Joined:** Sun Jan 18, 2009 2:12 am **Posts:** 16

It is no problem as long as you know the bugs of your tools you use

And right now i am working on my own project

And NASM is my favorite assambler

so i dont want to change the assambler

iansjack · **Posted:** Sun Apr 20, 2014 4:35 am

You obviously need to know your tools, the processor you are writing instructions for, and the algorithms that you are using. Any tool can only protect you from a certain number of mistakes - in the end it's up to the programmer to get the code right in the first place, both syntax and logic. If you're happy with the limitations of the tools then stick with it.

OSDev.org

[SOLVED] Is this a Bug in NASM?

Who is online