relocatable real-mode code in ELF?

[stsp]

Hi.

I wonder if it is possible to create the
relocatable real-mode code with nasm,
outputting it into an ELF format.
For example if we have the code like
jmp     TGROUP:label
then we can define TGROUP in a linker
script, but it won't be relocatable.
I read the doc about the relocations in nasm,
and it seems to mostly support only got
and plt relocations.
What I think would be useful for the real-mode
code, is the copy relocations like R_386_COPY,
so that in the example above, the value of
the variable TGROUP can just be copied
by dynamic linker, and used as a segment value.
(if someone wonders why putting real-mode code
into elf - well, its a common practice actually
when the resulting stuff is then executed under VTx)

What do people think?
Does nasm currently support creating the
relocatable real-mode code in ELF, or if not -
would something like R_386_COPY be an
adequate solution to the problem?

[stsp]

I have now found this document:
https://github.com/tkchia/build-ia16/blob/master/elf16-writeup.md
Which mentions the R_386_SEGRELATIVE
relocation, which may also allow the run-time
relocations of real-mode code.
But I can't find such relocation in a nasm sources...
Where is it?
Is it something that is only being planned?

[Elawig57]

That was so amazing and that was so great.
MIBridges

[Frank Kotler]

Nasm's "-f elf" ts protected mode code. If you can get real mode out of it (?). what OS would you run it in? What is the state of bit 0 of cr0? They calculate addresses by a different scheme!

What do you think, Elawig57?

Confused,
Frank

[fredericopissarra]

Nasm's "-f elf" ts protected mode code. If you can get real mode out of it (?). what OS would you run it in? What is the state of bit 0 of cr0? They calculate addresses by a different scheme!

What do you think, Elawig57?

Confused,
Frank

Nope... -felf (or -felf32) is an ELF32 format. If you create an apropriate script for ld you can generate a binary file from this linkable format...

[fredericopissarra]

Simple example for Linux:

Code: [Select]

; test.asm
  bits 16

  section .text

  extern f

_start:
  mov ax,1
  call dword f     ; Important because the code in C will return with RETD!
  mov ah,0x4c
  int 0x21

Code: [Select]

// func.c
__attribute__((regparm(1)))
short int f( short int x ) { return x + x; }Here's the linker script:

Code: [Select]

/* output.ld */
OUTPUT_FORMAT(binary)
OUTPUT_ARCH(i386)
ENTRY(_start)

SECTIONS
{
  . = 0x0100;

  .text : { *(.text16) *(.text) }
  .rodata : { *(.rodata) }
  .data : { *(.data) }

  _bss_begin = .;
    .bss : { *(.bss) }
  _bss_end = .;

  /DISCARD/ : { *(.comment) *(.eh_frame) *(.note.GNU-stack) }
}And the entire compilation/linkage:

Code: [Select]

$ nasm -felf32 -o test.o test.asm
$ cc -O2 -fomit-frame-pointer -fcf-protection=none -m16 -fno-pie -c -o func.o func.c
$ ld -T output.ld -nostdlib -z norelro -o test.com test.o func.oNow we have a 16 bits .COM file to run on DOS.

Notice gcc will still create a 32 bits code (pointers are still viewed as in FLAT memory model) and both NASM and GCC will create a elf32 object...

Code: [Select]

$ ndisasm test.com
00000000  B80100            mov ax,0x1
00000003  66E807000000      call dword 0x10
00000009  B84C00            mov ax,0x4c
0000000C  CD21              int 0x21
0000000E  6690              xchg eax,eax
00000010  6601C0            add eax,eax
00000013  66C3              retd

[Frank Kotler]

Okay, thanks Fred,

You know what you're doing.

Still looks like insanity to me. I see what you're doing but I don't know why!

I actually replied to this post to see if Elawig was "for real" or not.

Best,
Frank

[fredericopissarra]

Still looks like insanity to me. I see what you're doing but I don't know why!

Hehehe... Look like it is insane, isn't it?
The thing is, what is writen on the sections in an object file isn't "proteced mode" per se. Just a buch of bytes. When you use bits 32 in nasm the only thing you are telling to the compiler is: Don't put 0x66 or 0x67 prefix before the instructions using E?? registers. When you use bits 16 it's the other way around (E?? registers in instructions will generate 0x66 or 0x67 prefix). bits 64 is the same as bit 32, but allows the REX prefix.

NASM doesn't know if you are dealing with protected mode or not, nor the bytes writen on ELF object files.

In fact, Linux source uses this to build the master boot sector in arch/x86/boot/* source tree, but using GAS, instead of NASM.

I actually replied to this post to see if Elawig was "for real" or not.

A prudent test, given the huge amount of spam in recent weeks...

[]s
Fred

[fredericopissarra]

Another example (compile on Linux):

Code: [Select]

$ make
$ make run    # to run with qemu.Sorry, the coments are in pt_BR (I am brazilian).