[bitlug] Re: ELF??

  • From: Peeyush Prasad <peeyush@xxxxxxxxxx>
  • To: bitlug@xxxxxxxxxxxxx
  • Date: Fri, 11 Nov 2005 01:12:46 +0530 (IST)

On Wed, 9 Nov 2005, Pavan Chandrashekar - Sun Microsystems wrote:

Any body else interested in ELF stuff?? using it perhaps??

Interested?? In using ELF?? Oh..., should i say just *yes*? Bread and butter man, as boss says :-) [pun intended]

DSP is binary, objcopy does that in a trice... but I need to know what the compiler has done to create the object file, and modify that for my architecture...

Ok. First of all, what do you use to build the ELF that you want to dump onto the DSP? A cross compiler I suppose. And *no* shared objects, I presume, unless you have some kind of Virtual MM on that DSP system you are talking about.

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
.. or maybe I have to get position-independent-code and then just specify the start address ?

-- 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).


Other related posts: