ld: access beyond end of merged section

Question

i'm trying to link a simple c program on an arm debian machine (a raspberry pi) and when linking the ogject file the linker returns me the error in the subject.

my program is as simple as

simple.c:

 int main(){
   int a = 2;
   int b = 3;
   int c = a+b;
 }

i compile it with

$>gcc -o simple.obj simple.c

and then link it with

$>ld -o simple.elf simple.obj
ld: simple.obj: access beyond end of merged section (33872)

i can't understand why... if i try to read the elf file with objdump -d it doesn't manage to decompile the .text section (it only prints address, value, .word and again value preceded by 0x) but the binary data is the same as the one i get from the decompiled simple.obj.

the only difference is in the loading start (and consequent) addresses of the binary data: the elf file starts at 0x8280, the object file starts at 0x82a0.

what does all this mean?

EDIT:

this is the dump for the obj file: http://pastebin.com/YZ94kRk4

and this is the dump for the elf file: http://pastebin.com/3C3sWqrC

i tried compiling with -c option that makes gcc stop after assembly time (it already did the linking part) but now i have a different problem: it says that there is no _start section in my object file...

the new dumps are:

simple.obj: http://pastebin.com/t0TqmgPa

simple.elf: http://pastebin.com/qD35cnqw

Answer 1

You are misunderstanding the effect of the commands you ran. If you run:

$ gcc -o simple.obj simple.c

it already creates the program you want to run, it's already linked. You don't need to link it again, especially by running ld directly unless you know what you are doing. Even if its extension is obj, it doesn't matter, it's just the name of the file, but the content of the file is already a complete Linux program. So if you run:

$ ./simple.obj

it will execute your code.

You usually don't call ld directly, but instead you use gcc as a front-end to compile and link. This is because gcc takes care of linking also important libraries that you are not linking such as the startup code, and that's the reason why your second attempt resulted in "no _start section" or something like that.

Answer 2

Could you print the output of the objdump -d command?

Btw, notice that 33872 == 0x8450.

I am not familiar with raspberry PI's memory map, so if you'r following any tutorials about this or have some other resource to help me help you out - it would be great :)