Problem: ld relocation truncated to fit R_386_16

[amirsadig]

I am trying to use unreal mode to call bios. therefore I have added some code to my starter code of my kernel to switch to unreal mode.

Code: Select all

[BITS 32]
entry:
; check if data segment linked, located, and loaded properly
   mov eax,[ds_magic]
   mov [mboot_info], ebx
   cmp eax,DS_MAGIC
   je ds_ok

; display a blinking white-on-blue 'D' and freeze
   mov word [0B8000h],9F44h
   jmp short $
ds_ok:

; stop using bootloader GDT, and load new GDT
   lgdt [gdt_ptr]

   mov ax,LINEAR_DATA_SEL
   mov ds,ax
   mov es,ax
   mov ss,ax
   mov fs,ax
   mov gs,ax
   jmp LINEAR_CODE_SEL:testrealmode
testrealmode:
      cli
; ------ Ensure that code- and stack-segment limits are 64KB.
      mov   eax, ds16
      mov   ss, eax
      jmp   dword cs16:.2


[BITS 16]
; ------ Disable protected mode; jump to real-mode segment.
   .2:   
      mov   eax, cr0
      and   eax, 0xFE
      mov   cr0, eax
      jmp   word 0x00:.3
; ------ Load stack- and data-segment registers
; ------ with proper real-mode segment numbers.
   .3:   xor   ax, ax
      mov   ds, ax
      mov   es, ax
      mov   fs, ax
      mov   gs, ax
      mov   ss, ax

; ------ Enable A20 line (and thus high memory).
; ------ [http://www.karig.net/0003.html]
      mov   al, 0xD1
      out   0x64, al
      mov   al, 0x03
      out   0x60, al

      sti

; ------ Prove this code works -- print "YYYYYYYY" if it does.
testcode:
      mov   al, 'Y'
      mov   edi, 0x2FFF00
      mov   dx, 0xABCD
      mov   [edi], dx
      mov   bx, [edi]
      cmp   bx, 0xABCD
      je   .1
      mov   al, 'N'
   .1:   xor   bh, bh
      mov   bl, 0x20
      mov   cx, 8
      mov   ah, 9
      int   0x10

; ------ Halt computer.
      jmp   $

nasm compile it without warning, but as I link it, I receive this error

Code: Select all

in function testrealmode.2:
relocation truncated to fit R_386_16

[Pype.Clicker]

you have some 32-bits address that need to be relocated in order to be linked, but the linker has not enough room to store the relocated 32-bit value in the 16-bit field ...

If you're lucky, this will not harm because highest 16 bits will be zeroes. if you're not lucky, some jump somewhere will not behave as expected.

The wisest move is to put all of your 16 bits in a separated ASM that you ORG to some location you like (e.g. assume executed at 0x2000:0000) and incbin it in your kernel. Just before calling that code, you'll copy it at its expected location.

[amirsadig]

If you're lucky, this will not harm because highest 16 bits will be zeroes. if you're not lucky, some jump somewhere will not behave as expected.

what did you mean if i am lucky? did you mean with executing or compiling?

I can not compile the code. how normaly we could mix 16 and 32 bits code in one program?

[Candy]

If you're lucky, this will not harm because highest 16 bits will be zeroes. if you're not lucky, some jump somewhere will not behave as expected.

what did you mean if i am lucky? did you mean with executing or compiling?

I can not compile the code. how normaly we could mix 16 and 32 bits code in one program?

did you consider using the search function? 10 days before this post I answered an EXACT same question. Pype even gave some good advice there, which he repeated there. I'm not going to be that social. It was about reentering realmode (one of those threads).

[Pype.Clicker]

http://www.mega-tokyo.com/forum/index.p ... 43;start=0

i guess that's the thread Candy was talkin' about

Code: Select all

search in [x] Os Dev, Design, FAQ, etc
   (leave other unchecked)
for [relocation_____]
by user [_______________] (left empty)
search in [x] subject [x] message
min age : [0 ] [0 ] 
max age : [ 0 ] hours [ 30 ]days 
display max of [ 50 ] posts 

just in case ... it took me 3 or 4 attemps before 'search' gave the result. multiple word search doesn't seem to work very well and if there are more than N matches, only oldest N matches will be shown ...