Object size info
Paul Floyd
Does anyone know of a tool for Mac OS X that will llow me to examine the
sizes of objects? In particular I'm looking to find the size of
global/static data objects, and functions.
This is easy on OSes that use ELF for object code. I've tried using GNU
nm, but the size field doesn't seem to exist in Mach-o. GNU nm has a
stab (no pun intended) at working out the sizes by crossing its fingers
and hoping that the diffs of the indices give the sizes. But the values
were hopelessly wrong when I tried it.
Any takers?
A bientot
Paul
Gregory Weston
Paul Floyd <ro...@127.0.0.1> wrote:
This probably falls into the category of "What are you _really_ trying
to do?"
Paul Floyd
Um. Measure the sizes of objects. Like I said.
I'm writing an article for a programming magazine. I've done some
measurements on Linux and Solaris. But I'm a bit stuck on Mac OS X
(haven't tried windows yet). The best that I can think of is to use nm
-n then calculate the diffs (except for the last line). This is probably
what GNU nm tries (and fails) to do.
A bientot
Paul
Reinder Verlinde
Paul Floyd <ro...@127.0.0.1> wrote:
> On Thu, 26 Jul 2007 15:59:46 -0400, Gregory Weston <u...@splook.com> wrote:
> > In article <slrnfaht2...@bourbiere.local>,
> > Paul Floyd <ro...@127.0.0.1> wrote:
> >
> >> Hi
> >>
> >> Does anyone know of a tool for Mac OS X that will llow me to examine the
> >> sizes of objects?
'Object' is quite a generic term.
- If 'object' is object code, what's wrong with 'ls -l'?
- If 'object' is a C++ object or C/C++ struct, what's wrong with
"sizeof C"?
> >> In particular I'm looking to find the size of
> >> global/static data objects, and functions.
Functions do not necessarily have a well-defined size (I am not aware of
any compiler doing this, but a really smart compiler could make
functions share code without doing a jump, call, or whatever, or could
generate multiple versions of a function with slight variations, for
instance a special one that saves fewer registers). If you want to
answer "how many bytes of code does the compiler produce for function
x", what's wrong with disassembling using "otool -tV" and counting?
> > This probably falls into the category of "What are you _really_ trying
> > to do?"
>
> Um. Measure the sizes of objects. Like I said.
See above, you may need to be more specific about what you mean by
'object'.
> I'm writing an article for a programming magazine. I've done some
> measurements on Linux and Solaris. But I'm a bit stuck on Mac OS X
> (haven't tried windows yet). The best that I can think of is to use nm
> -n then calculate the diffs (except for the last line). This is probably
> what GNU nm tries (and fails) to do.
Reinder
Paul Floyd
<rei...@verlinde.invalid> wrote:
>
> 'Object' is quite a generic term.
> "sizeof C"?
sizeof is OK for data objects.
>> >> In particular I'm looking to find the size of
>> >> global/static data objects, and functions.
>
> Functions do not necessarily have a well-defined size (I am not aware of
> any compiler doing this, but a really smart compiler could make
> functions share code without doing a jump, call, or whatever, or could
> generate multiple versions of a function with slight variations, for
> instance a special one that saves fewer registers).
That's a big "could". All of the major object formats (elf, coff) assume
single entry. Mach-o as well I guess.
> If you want to
> answer "how many bytes of code does the compiler produce for function
> x", what's wrong with disassembling using "otool -tV" and counting?
I'd rather not. At least, not if I want to do it more than a couple of
times.
My best bet looks like using output like
00000012 T X::setA(bool)
0000002a T X::getA() const
00000040 T X::setB(bool)
00000064
and calculating the sizes
setA = 2a-12, getA = 40-2a, setB = 64-40 and so on
>> > This probably falls into the category of "What are you _really_ trying
>> > to do?"
>>
>> Um. Measure the sizes of objects. Like I said.
>
> See above, you may need to be more specific about what you mean by
> 'object'.
Try running Solaris nm, or Linux nm with -f sysv, and compare the
output to Mac OS X nm, and you'll see what I'm missing.
A bientot
Paul
glenn andreas
Paul Floyd <ro...@127.0.0.1> wrote:
> > Functions do not necessarily have a well-defined size (I am not aware of
> > any compiler doing this, but a really smart compiler could make
> > functions share code without doing a jump, call, or whatever, or could
> > generate multiple versions of a function with slight variations, for
> > instance a special one that saves fewer registers).
>
> That's a big "could". All of the major object formats (elf, coff) assume
> single entry. Mach-o as well I guess.
>
Um, no.
Nothing in the mach-o format has anything to do with "single entry" -
there are just locations (offsets) within the section. The data
structures for mach-o are documented in /usr/include/mach-o - you can
see the dynamic link edit symbol table is composed of various symbols
that use the nlist structure:
struct nlist {
union {
#ifndef __LP64__
char *n_name; /* for use when in-core */
#endif
int32_t n_strx; /* index into the string table */
} n_un;
uint8_t n_type; /* type flag, see below */
uint8_t n_sect; /* section number or NO_SECT */
int16_t n_desc; /* see <mach-o/stab.h> */
uint32_t n_value; /* value of this symbol (or stab offset)
*/
};
There are no implicit or explicit sizes for anything at that granularity
(you could search through all the nlist entries and find the "next" one
and assumes that the difference is the "size" but that is only sometimes
reliable)
FORTRAN has the ability to declare a routine with multiple entry points
in a single "function" (you can have, for example, a subroutine to do
exponentiation which has an entry point that does square root by
explicitly setting the exponent to 0.5), so any run time architecture
that supports FORTRAN (which is pretty much all the common ones) needs
to be able to support such a thing.
Paul Floyd
> In article <slrnfai76...@bourbiere.local>,
> Paul Floyd <ro...@127.0.0.1> wrote:
>> > Functions do not necessarily have a well-defined size (I am not aware of
>> > any compiler doing this, but a really smart compiler could make
>> > functions share code without doing a jump, call, or whatever, or could
>> > generate multiple versions of a function with slight variations, for
>> > instance a special one that saves fewer registers).
>>
>> That's a big "could". All of the major object formats (elf, coff) assume
>> single entry. Mach-o as well I guess.
> Um, no.
>
> Nothing in the mach-o format has anything to do with "single entry" -
> there are just locations (offsets) within the section. The data
> structures for mach-o are documented in /usr/include/mach-o - you can
I'll have a read of that.
[snip non SE]
This seems somewhat academic - is there any way to write coroutines and
MESE/MEME with GCC?
[snip FORTRAN]
I'm not really interested in FORTRAN.
Anyway, I've now got a reasonably working solution. I still can't the
size of the last symbol, and there seems to be a jump between the end of
the text segment and the start of the "S" symbols.
A bientot
Paul
Reinder Verlinde
Paul Floyd <ro...@127.0.0.1> wrote:
> Anyway, I've now got a reasonably working solution.
I am not sure about that. Earlier, you wrote:
> I'm writing an article for a programming magazine. I've done some
> measurements on Linux and Solaris. But I'm a bit stuck on Mac OS X
> (haven't tried windows yet). The best that I can think of is to use nm
> -n then calculate the diffs (except for the last line). This is probably
> what GNU nm tries (and fails) to do.
If you are going to compare lengths of code blocks inside executables,
aren't you comparing compilers, rather than operating systems?
So, I'll rephrase what Gregory Weston said in article
<uce-9D1248.1...@comcast.dca.giganews.com>:
<u...@splook.com> wrote:
"What problem do you think this would be a solution for?"
Reinder
Paul Floyd
<rei...@verlinde.invalid> wrote:
> In article <slrnfakna...@bourbiere.local>,
> Paul Floyd <ro...@127.0.0.1> wrote:
>
>> Anyway, I've now got a reasonably working solution.
>
> I am not sure about that. Earlier, you wrote:
You're not sure that my solution works reasonably well? I am.
>> I'm writing an article for a programming magazine. I've done some
>> measurements on Linux and Solaris. But I'm a bit stuck on Mac OS X
>> (haven't tried windows yet). The best that I can think of is to use nm
>> -n then calculate the diffs (except for the last line). This is probably
>> what GNU nm tries (and fails) to do.
>
> If you are going to compare lengths of code blocks inside executables,
> aren't you comparing compilers, rather than operating systems?
nm doesn't give the size of code blocks. It displays symbols, plus some
other data.
Strictly speaking, I'm measuring compiler, OS and platform values. Since
I don't have the Intel compiler for Mac (and don't know of any other
compiler for Intel Mac) then my sole Mac sample will be x86/gcc.
> So, I'll rephrase what Gregory Weston said in article
><uce-9D1248.1...@comcast.dca.giganews.com>:
> <u...@splook.com> wrote:
>
> "What problem do you think this would be a solution for?"
Finding the size of objects in compiled files. I think that I've been
pretty clear about that. For the short term, I'm just interested in
function sizes. For the longer term, anything that's in .o, .a, .dylib
or application files.
A bientot
Paul