flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > Backawrd jumps in ELF (16 bit)

Author
Thread Post new topic Reply to topic
Jeronimus Linuxius



Joined: 28 Jun 2007
Posts: 37
Jeronimus Linuxius
I have a section in an ELF object where I will put some code I want to assemble for RM. However, fasm is not allowing me to use backward relative jumps.
Code:
format ELF

section ".text16" executable
use16

_start16:
;(...)
;This one works:
                je      .cpuok
              
            mov     si, wrongcpu
                call    print
               xor     ah, ah          ;Wait for char...
           int     16h
         int     19h             ;Reboot...
       .cpuok:
;(...)
;But this one does not:
           ;Enabling A20 gate
          cli
 @@: in      al, 0x64
            test    al, 1 shl 1             ;Bit 1 = input buffer status
                jnz     @b
;(...)    
The output is:
Code:
flat assembler  version 1.67.21  (16384 kilobytes memory)
start.asm [nn]:
                jnz     @b
error: address sizes do not agree.    


Is this a bug?
JJ
Post 14 Jul 2007, 01:23
View user's profile Send private message MSN Messenger Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
I wonder what OS would load and allow execution of this ELF-16 Confused
Post 14 Jul 2007, 04:49
View user's profile Send private message Reply with quote
Jeronimus Linuxius



Joined: 28 Jun 2007
Posts: 37
Jeronimus Linuxius
NTOSKRNL_VXE wrote:
I wonder what OS would load and allow execution of this ELF-16 :?
It's just an object that will be linked into a binary executable by ld...
Duh!

Now, another obvious point, in case you don't get it...
This will be linked with some C code compiled by gcc, that's why I don't use format bin.

JJ
Post 14 Jul 2007, 16:39
View user's profile Send private message MSN Messenger Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
The problem is that the destination address is above of the limit of 16-bit numbers. I again forgot the exact reason (Alzheimer is killing me), but I think it has something to do with the fact that a 16-bit jump only does "IP = IP + rel" but it is required to do "EIP = EIP + rel". You can use "jnz dword @b" and that way it will work (but note that on 16-bit mode it will use EIP and on 32-bit mode it will use IP). Aditionally you can adjust the origin to something below 64K (though, this kills relocations, I think). Anyway I think you will have more troubles in future because the format is intended for 32-bit code, there is no 16-bit relocations so I don't know how your object will work with non-relative references.

If it's possible for you make a loader that sets up the processor to 32-bit and loads your linked elf.
Post 14 Jul 2007, 17:16
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Post 14 Jul 2007, 18:47
View user's profile Send private message Reply with quote
Jeronimus Linuxius



Joined: 28 Jun 2007
Posts: 37
Jeronimus Linuxius
LocoDelAssembly wrote:
Anyway I think you will have more troubles in future because the format is intended for 32-bit code, there is no 16-bit relocations so I don't know how your object will work with non-relative references.
No. The 16bit code is only intended as a stub that tests for 386+ and enables protected mode, then it jumps to somewhere inside .text. Also, I remember that the ELF is going to be linked together with some other objects generated using fasm and some objects created with GCC.
Quote:
If it's possible for you make a loader that sets up the processor to 32-bit and loads your linked elf.
I think that I'll assemble the stub independently from the rest of the code and then simply concatenate the two final executables. However, I thing there are some other assemblers that don't have problems with this.

JJ
Post 14 Jul 2007, 21:58
View user's profile Send private message MSN Messenger Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:

However, I thing there are some other assemblers that don't have problems with this.

Too bad, that means that them don't care about the zeroing of the upper 16 bits of EIP.

Quote:

I think that I'll assemble the stub independently from the rest of the code and then simply concatenate the two final executables.


Well something like
Code:
format ELF 

section ".text16" executable 
_start16: file 'stub.bin' ; CF=0 if switching to 32-bit protected mode was successful
jc error
jmp _start32 ; Not simple jnc _start32 because if the label is too far a 32-bit rel will be generated but 16-bit mode will wrongly interpret it as 16-bit rel. The "jc error" has no problems because the error label is very near and the encoding is the same for both modes.

error:
use16
; Handle error here
.
.
.
    
Could work. Remember to make the stub position independent.
Post 14 Jul 2007, 22:43
View user's profile Send private message Reply with quote
Jeronimus Linuxius



Joined: 28 Jun 2007
Posts: 37
Jeronimus Linuxius
LocoDelAssembly wrote:
Quote:

However, I thing there are some other assemblers that don't have problems with this.
Too bad, that means that them don't care about the zeroing of the upper 16 bits of EIP.
I think they generate the form that only takes IP into account.
Quote:
Quote:
I think that I'll assemble the stub independently from the rest of the code and then simply concatenate the two final executables.
Well something like
Code:
(...)    
Thanks. I thought in using an ld command for the same effect, but looks like there is no way to do this in scripts.
Quote:
Could work. Remember to make the stub position independent.
It won't be position independent, however it will appear in the executable image in a compile-time know location, so there is no problem...

JJ
Post 14 Jul 2007, 23:56
View user's profile Send private message MSN Messenger Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:
I think they generate the form that only takes IP into account.

And that's the problem, taking into account only IP means that the jump performs "EIP = (EIP + displacement) and 0xFFFF" and that is pretty bad if target address is above 0xFFFF. With "format binary" happens the same if target is above 0xFFFF but fasm allows you to jump otherwise (because even with the zero extending EIP will be correctly set).

Quote:
however it will appear in the executable image in a compile-time know location, so there is no problem...


The final location is decided at link-time, since this is the main object (is it?) perhaps it will be located first but this is a linker's desition.
Post 15 Jul 2007, 03:27
View user's profile Send private message Reply with quote
Jeronimus Linuxius



Joined: 28 Jun 2007
Posts: 37
Jeronimus Linuxius
LocoDelAssembly wrote:
Quote:
I think they generate the form that only takes IP into account.
And that's the problem, taking into account only IP means that the jump performs "EIP = (EIP + displacement) and 0xFFFF" and that is pretty bad if target address is above 0xFFFF. With "format binary" happens the same if target is above 0xFFFF but fasm allows you to jump otherwise (because even with the zero extending EIP will be correctly set).
Well, that's no problem because the code running in RM needs to be below 1MB if it wishes to call the BIOS. Also, that code tests for 386+ and then prints an error message if it is not. Not that I expect finding a bunch of 8086s today, but it's logical (if I'm going to test for 386+, it makes sense not to use any 32-bit registers before making sure that they exist)...
Quote:
however it will appear in the executable image in a compile-time know location, so there is no problem...
The final location is decided at link-time, since this is the main object (is it?) perhaps it will be located first but this is a linker's decision.[/quote]Yes, but for some reason I've placed that code in a distinct section. The linker will put that section in the file start, because I'll tell it so, in the linker script.

JJ
Post 17 Jul 2007, 00:20
View user's profile Send private message MSN Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.