|icc linker question email@example.com (2009-03-05)|
|Re: icc linker question firstname.lastname@example.org (Bill Cox) (2009-03-18)|
|From:||Bill Cox <email@example.com>|
|Date:||Wed, 18 Mar 2009 12:38:07 -0700|
|Posted-Date:||18 Mar 2009 21:34:36 EDT|
> I'm well experienced with MIPS and PPC stuff for embedded systems.
> This is my first time with icc and Intel processors.
> We need to have _start at 0x00000000.
> For some reason, _start always keeps coming at an offset.
000000fb N .debug_line_seg7
> 000000fd T _start
> We need _start to be at 0x00000000.
> Any ideas on what I might be missing?
The book "Linkers and Loaders" has a great description of the
following issues, and I hope I haven't mis-stated them - my copy is in
some box in a storage locker so I'm writing from memory.
One thing you're missing is knowing a design goal of the ELF format.
One of them is to have a *very* simple executable-load function, where
the entire file is simply streamed into main memory. This means that
the ELF header is loaded as well, pushing the .text section higher in
the input memory block.
It *is* strange that the offset is an odd number. That's not usual
in my experience of ELF files.
I recommend using GNU readelf or objdump to look at the ELF file,
paying special attention to the file-offset and load-offset fields.
Basically, I think what you want violates the design of the ELF
format. Which is o.k. and I would call my changed format something
different, and you'll need to write your own loader. It could be as
simple as streaming the file into memory, and skipping the ELF header.
[I don't ever recall seeing ELF with junk at the front of the first
section, either, so I agree that he oughta dump it and find out what's
there. Re not remembering what "Linkers and Loaders" says, the prudent
thing to do would be to get a few extra copies so you always have one
close to hand. -John]
Return to the
Search the comp.compilers archives again.