views:

58

answers:

2

I have 2 obj files assembled with GNU as, they are:

  • a.o : my major program
  • b.o : some utility functions

a.o doesn't have an entry point. The final linked file will be loaded into memory and the execution will jump to its very beginning loaded address, where is the first instrucion of a.o.

Now I want to link them together with GNU ld. And I want to make a.o appear before b.o in the final file. How could I control this? Do I have to make a custom section and write in the linker script like this:

SECTIONS
{
  . = 0x7c00;
  .text : { *(.text) }
  .my_custom_section : { *(.my_custom_section) }
  .data : { *(.data) }
  .bss  : { *(.bss) }
}

OUTPUT_FORMAT(binary)

Update

Is there something wrong with this question? Did I post it wrong? If so, please let me know, guys. Many thanks.

Currently, I found that the command line sequence of the input files seems to be relevant.

If I do like this:

ld a.o b.o -o final.bin

Content from a.o will appear before b.o.

If I do like this:

ld b.o a.o -o final.bin

It will be otherwise.

Is it meant to be controlled like this?

A: 

The order of operations to ld is in fact relevant.

Unless explicitly stated somehow, the entry point is the first code byte of the first file on the list.

The resulting executable always has the contents of the .o files in invocation order. (with .a files it gets complicated).

Joshua
Thanks Joshua. This is kind of a delicate thing when I usually ignored.
smwikipedia
+2  A: 

According to the manual:

options which refer to files ... cause the file to be read at the point at which the option appears in the command line, relative to the object files and other file options

So the order of files in the binary is the order in which they appear on the command line.

Therefore, it is meant to be controlled as you mention in your update.

R Samuel Klatchko
Thanks R Samuel Klatchko. I read about this statement last night and I was not just sure about it then. Thanks for confirming it.
smwikipedia