Thursday, 15 April 2010

c - gcc/ld script ignores the start adress of the .text section and adds a lot of junk to my binary -


I am trying to create the following very small program in a raw binary file:

 Asm ("call sys_main \ n" // instant code "__asm_loop_halt: \ n" "jmp __asm_loop_halt \ n"); // then close the sys_main () {short * addr = (short *) 0x08b000; // Address EGA-VRAM * addr = 0x0f41; // Write white 'A' on black to screen}  

Because I'm trying to create a raw binary, write me a linker script gcc -std = gnu99-os - Nostdlib -m32 -march = i386 -ffreestanding -wl, - nmagic, - script = 386.ld -o test test.c :

  OUTPUT_FORMAT (binary) section {.text 0x0500: {* (.text); } .data: {* (.data); * (.bsc); * (Rodata.); } _heap = ALIGN (4); }  

The script should tell the linker that the code is starting to run on 0x500 and it should only make a binary file but when I do not collect binary, I get:

  00000000 E802000000 Call DWORD 0x7 00,000,005 EBFE JMP Low 0x5 00,000,007 55 push EBP 00,000,008 89E5 mov EBP, esp 0000000A 66C70500B0080041 MOV word [DWORD 0x8b000], 0xf41 -0F 00,000,013 5D Pop EBP 00,000,014 C3 Retired 00,000,015 0000 [Eax], add al 00,000,017 001,400 [eax + eax], dl ......  

appearingly still took the linker still 0x0 code The address is in the form and it also added a group of random data behind the last senseful 'retired' instruction, that is as big as the total 4 times code.

Is this data, why? It is there and what I did wrong to start my code at 0x0

Edit: Thanks to Eugene's tip with the map I came to know that behind .text section .eh_frame is responsible for the exception handling which can be easily deleted by calling GCC -fno-asynchronous-unwind-tables .


No comments:

Post a Comment