This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: linker problem


On 07 August 2007 07:59, Martin Knappe wrote:

> hi
> 
> i have a problem that has more to do with the gnu linker, but havent
> found an appropriate forum, so i thought i'd post it here; if someone
> can help me, good, if not, just ignore... :-)

  Redirected to the binutils list, which is that "appropriate forum" you were
looking for!  Please remember to send any follow-ups there too.

> suppose i have the following object file:
> 
> //begin main.o
> main.o:     file format elf32-i386
> 
> Disassembly of section .data:
> 
> 00000000 <.data>:
>    0:   ff                      (bad)
>    1:   ff                      (bad)
>    2:   ff                      (bad)
>    3:   ff                      .byte 0xff
> Disassembly of section .text:
> 
> 00000000 <.text>:
>    0:   06                      push   %es
>    1:   00 00                   add    %al,(%eax)
>    3:   00 06                   add    %al,(%esi)
>    5:   00 00                   add    %al,(%eax)
>    7:   00 48 65                add    %cl,0x65(%eax)
>    a:   6c                      insb   (%dx),%es:(%edi)
>    b:   6c                      insb   (%dx),%es:(%edi)
>    c:   6f                      outsl  %ds:(%esi),(%dx)
>    d:   2e 00 00                add    %al,%cs:(%eax)
> Disassembly of section .text:
> 
> 00000000 <start>:
>    0:   55                      push   %ebp
>    1:   89 e5                   mov    %esp,%ebp
>    3:   68 08 00 00 00          push   $0x8
>    8:   e8 fc ff ff ff          call   9 <start+0x9>
>    d:   89 ec                   mov    %ebp,%esp
>    f:   5d                      pop    %ebp
>   10:   c3                      ret
> 
> //end main.o
> 
> 
> I link this file together with two other object files:
> 
> ld main.o video.o utilities.o -e start -N -o boot.bin --oformat binary
> -T script
> 
> The linker script is as follows:
> 
> //begin script
> 
> SECTIONS
> {
>   . = 0x0;
>   .text : { *(.text) }
>   .data : { *(.data) }
>   .bss : { *(.bss) }
> }
> 
> //end script
> 
> When I disassemble the linked result, I get this:
> 
> 
> //begin
> 00000000  06                push es
> 00000001  0000              add [eax],al
> 00000003  0006              add [esi],al
> 00000005  0000              add [eax],al
> 00000007  004865            add [eax+0x65],cl
> 0000000A  6C                insb
> 0000000B  6C                insb
> 0000000C  6F                outsd
> 0000000D  2E0000            add [cs:eax],al
> 00000010  55                push ebp
> 00000011  89E5              mov ebp,esp
> 
> ...and so on
> //end
> 
> You can see clearly here that what is placed right at the start of the
> linked result is the code that comes in section .text of the object file
> just before the function "start" EVEN THOUGH I have specified in my
> linker command that "start" be the entry point. 

  Ah, but unfortunately that's not how the -e entrypoint works.  All that -e
does is stores the address of the supplied symbol in whatever header field is
used to store the starting address in the output object file format.  For
formats like ELF and such, that have headers and internal structure, that
works, and the runtime loader uses that -e value as the entrypoint.  But in
plain binary output, well... you get a binary that you're supposed to begin
executing from that -e address, not a binary that has the code from that
address at zero.

> The problem is that this
> part of section .text is not only NOT supposed to be the start of my
> code, but that it is really READONLY data placed into the .text section
> by the compiler for some reason. Can I do anything about this? Is there
> a way to make the linker place this AFTER all executable code (i.e.
> where data and bss are  placed)...

  The sections (text, data, bss) from each of the object files you specify are
concatenated together in the order you specify those object files on the
commandline.  So the code that ends up at address 0 will be the code from the
very first .text section of the very first .o file on the command line.  You
could do this by moving your start routine into a separate .o file and linking
that one first, or by putting it into a custom-named section all of its own
and listing that first in your linker script, or you could generate a .o file
that just contains a "jmp start" and link that first.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]