[bitlug] Re: ELF??

  • From: Pavan T C <Pavan.Chandrashekar@xxxxxxx>
  • To: bitlug@xxxxxxxxxxxxx
  • Date: Fri, 11 Nov 2005 13:02:32 +0530

yeah, am using an ADSP blackfin processor here, got a gcc port for that... and no shared objects...
I'm interested in creating an executable that can be loaded at an address that I specify... looked at the --entry option in ld, that changed the entry address, but a readelf of the executable shows the section addresses have not changed...
For example, if you create an exe on your PC gcc and have a look and the disassembled output, you see that the start address is always 0x8048244, and that the other sections have addresses wrt to this start address.
Not so in my case.. I see the start address change, but not the section addrs.
In my case, I can use the --section-start <section name> <my addr> option to ld and specify addresses of my sections, but there has to be an easier way... maybe I have to specify somewhere that I want absolute code or
something...

One better way to do it is to use a mapfile for the linker.

I dont think the relocatable objects are the defaults when you compile. On solaris (I dont have a linux box here), i need to use ld -r to specify that I need a relocatable object/exe. To verify that, I did a gcc -c and then used objdump -d to check the addresses and they were all relative to zero.

To see what gcc is using to build you executable, use gcc -v.
That should give you a fair idea of what you should override by passing the linker options via gcc in the command line to get what you want.
I'll see if I can play around with the linker during the weekend.


.. or maybe I have to get position-independent-code and then just specify the start address ?

I dont know how that will work when you have multiple objects being linked. I feel it is better to go with the default placement and use the mapfile to tweak what is impt for you.


TC


-- P


Do you want to know how the object file (.o) is created or the executable - static or shared?


Plain relocatable object files are created by the assembler with the help of opcodes for instructions and the addressing formats that are used for accessing data, and of course the data itself. Refer Instruction formats for concerned architectures. How these contents are placed into corresponding sections is something that is extremely compiler specific.

For example, remember .rodata? GCC prevents the writing of data in this section. The solaris CC also has the .rodata, but allows writing to data in here.

Archives(.a) are created (using ar) by bundling the symbol information from all the relocatable objects that are part of the archive into a symbol table.

Shared objects are something that i am not very much aware of (ironically). However, the usage of symbols whose definitions are in shared objects need the runtime linker to manipulate the references to point to the right definitions, at runtime.

And, just to be correct on the terminology, all these are done by the link editor (ld).

TC




Other related posts: