Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Dave Hylands <dhylands@br...> - 2004-09-21 16:56:45
Hi Greg, Semmler,
> Here's a piece of a map file I have:
> .data 0x004c9000 0x10=20
> 0x004c9000 _argc
> 0x004c9004 _argv
> .data 0x004c9010 0x10=20
The 0x10 over on the right tells you how big the portion of .data is
from crt2.o. Note that trying to calculate symbol size is kind of dodgy.
This is because you're only seeing the public symbols. Variables which
are declared using static take up space but don't show in the map file.
> The .data section seems to be sorted by address. I think we can
> conclude from this map that main()'s arguments start at the
> address given, and that _argc probably takes four bytes, and
> that _argv takes no more than twelve bytes, though it probably
> takes less. I'm guessing that the difference between successive
> addresses reflects not just object size but also alignment.
Yes, alignment will be absorbed into your variables. If you produce the
assembly (using mingw32-gcc -S), you'll see something like this:
(The C code was "int z =3D 9;"), so 16 byte alignment is being used. For
i386, the ".align n" means 2 to the power n. Some processors interpret
".align n" as align to an n byte boundary.
> I'm casually assuming that the authors consider the map layout
> self-explanatory, but if you find a good document that explains
> this in detail, I'd like to hear about it.
> Maybe something like 'objdump' or 'size' would be more useful
> to you. Last time I checked (years ago) they were documented in
> the 'binutils' manual.
Yep - still are.
Vancouver, BC, Canada