Backawrd jumps in ELF (16 bit)

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

Author

Thread

Jeronimus Linuxius

Joined: 28 Jun 2007
Posts: 37

Jeronimus Linuxius 14 Jul 2007, 01:23

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

14 Jul 2007, 01:23

DOS386

Joined: 08 Dec 2006
Posts: 1903

DOS386 14 Jul 2007, 04:49

I wonder what OS would load and allow execution of this ELF-16 Confused

14 Jul 2007, 04:49

Jeronimus Linuxius

Joined: 28 Jun 2007
Posts: 37

Jeronimus Linuxius 14 Jul 2007, 16:39

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

14 Jul 2007, 16:39

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 14 Jul 2007, 17:16

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.

14 Jul 2007, 17:16

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 14 Jul 2007, 18:47

Now that I took my pills:
http://board.flatassembler.net/topic.php?p=55118#55118
http://board.flatassembler.net/topic.php?t=5162

14 Jul 2007, 18:47

Jeronimus Linuxius

Joined: 28 Jun 2007
Posts: 37

Jeronimus Linuxius 14 Jul 2007, 21:58

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

14 Jul 2007, 21:58

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 14 Jul 2007, 22:43

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.

14 Jul 2007, 22:43

Jeronimus Linuxius

Joined: 28 Jun 2007
Posts: 37

Jeronimus Linuxius 14 Jul 2007, 23:56

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

14 Jul 2007, 23:56

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 15 Jul 2007, 03:27

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.

15 Jul 2007, 03:27

Jeronimus Linuxius

Joined: 28 Jun 2007
Posts: 37

Jeronimus Linuxius 17 Jul 2007, 00:20

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

17 Jul 2007, 00:20

< 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