«

Hi All,

I need to know the memory required by a c program. Is there any
tool/utility which can give me the memory usage in terms of DATA
segment, TEXT segment, BSS segment etc.

I am working on linux platform and my target is ARM processor. But i
guess it should not matter. Actually i need to know both RAM & ROM
usage.

I searched the messages posted on this group as well as on the embedded
group but could not find anything meaningful. Would appreciate the
help.

Regards
Hemal

Hemal wrote:
> Hi All,
>
> I need to know the memory required by a c program. Is there any
> tool/utility which can give me the memory usage in terms of DATA
> segment, TEXT segment, BSS segment etc.
>
> I am working on linux platform and my target is ARM processor. But i
> guess it should not matter. Actually i need to know both RAM & ROM
> usage.
>
> I searched the messages posted on this group as well as on the embedded
> group but could not find anything meaningful. Would appreciate the
> help.
>
> Regards
> Hemal

look for "size" in the compilers bin directory

-Lasse

In article < .com>,
Hemal <> wrote:

>I need to know the memory required by a c program. Is there any
>tool/utility which can give me the memory usage in terms of DATA
>segment, TEXT segment, BSS segment etc.

You might be able to get some of those, but it isn't difficult to
prove that there cannot be any general tool which can reliably
examine source and calculate the amount of stack and heap required
by arbitrary programs.

(For example, you can write a simple iterative search for odd
"perfect numbers", and when you find one, allocate that number
of bytes. Despite extensive searches, there are no known odd
perfect numbers, but there is also no proof that they cannot
exist, so in order for a program to be able to analyze the source
and predict its memory usage, the examining program would first have to
solve the "odd perfect number" problem...)


>I am working on linux platform and my target is ARM processor. But i
>guess it should not matter.

Yes, it matters a lot, as a number of operating systems do not
use DATA or TEXT or BSS segments at all.

>Actually i need to know both RAM & ROM
>usage.
>
>I searched the messages posted on this group as well as on the embedded
>group but could not find anything meaningful. Would appreciate the
>help.

It is not surprising you didn't find it in comp.lang.c, as such
tool would be platform dependant and we strongly avoid discussion of
platform dependancies here. You should check a linux programming
group.


[Off topic]
If your platform offers the elfdump or dwarfdump tools, you might
be able to dig out some information of interest.

Also, your platform's linker might support a "registry file",
possibly named so_locations .

--
All is vanity. -- Ecclesiastes

Thanks. "size" gave me the information & i believe it is ROM size.

Although below question may not belong to this group but in
continuation to above question

Is there any difference between RAM & ROM size for same code & if yes
why? My understanding is ROM size is large as it contains additional
ReadOnly TEXT section.

Thanks
-Hemal

wrote:
> Hemal wrote:
> > Hi All,
> >
> > I need to know the memory required by a c program. Is there any
> > tool/utility which can give me the memory usage in terms of DATA
> > segment, TEXT segment, BSS segment etc.
> >
> > I am working on linux platform and my target is ARM processor. But i
> > guess it should not matter. Actually i need to know both RAM & ROM
> > usage.
> >
> > I searched the messages posted on this group as well as on the embedded
> > group but could not find anything meaningful. Would appreciate the
> > help.
> >
> > Regards
> > Hemal
>
> look for "size" in the compilers bin directory
>
> -Lasse

Thanks for your help but i couldn't make out from what you mean by "odd
perfect numbers".

-Hemal
Walter Roberson wrote:
> In article < .com>,
> Hemal <> wrote:
>
> >I need to know the memory required by a c program. Is there any
> >tool/utility which can give me the memory usage in terms of DATA
> >segment, TEXT segment, BSS segment etc.
>
> You might be able to get some of those, but it isn't difficult to
> prove that there cannot be any general tool which can reliably
> examine source and calculate the amount of stack and heap required
> by arbitrary programs.
>
> (For example, you can write a simple iterative search for odd
> "perfect numbers", and when you find one, allocate that number
> of bytes. Despite extensive searches, there are no known odd
> perfect numbers, but there is also no proof that they cannot
> exist, so in order for a program to be able to analyze the source
> and predict its memory usage, the examining program would first have to
> solve the "odd perfect number" problem...)
>
>
> >I am working on linux platform and my target is ARM processor. But i
> >guess it should not matter.
>
> Yes, it matters a lot, as a number of operating systems do not
> use DATA or TEXT or BSS segments at all.
>
> >Actually i need to know both RAM & ROM
> >usage.
> >
> >I searched the messages posted on this group as well as on the embedded
> >group but could not find anything meaningful. Would appreciate the
> >help.
>
> It is not surprising you didn't find it in comp.lang.c, as such
> tool would be platform dependant and we strongly avoid discussion of
> platform dependancies here. You should check a linux programming
> group.
>
>
> [Off topic]
> If your platform offers the elfdump or dwarfdump tools, you might
> be able to dig out some information of interest.
>
> Also, your platform's linker might support a "registry file",
> possibly named so_locations .
>
> --
> All is vanity. -- Ecclesiastes

In article <. com>,
Hemal <> wrote:
>Thanks for your help but i couldn't make out from what you mean by "odd
>perfect numbers".

http://en.wikipedia.org/wiki/Perfect_number

The exact meaning wasn't relevant to the discussion; the
point was that it was there was no known theoretical way to
solve the problem.

Recapping, the point was that there *cannot* be a program
which reliably predicts run-time memory usage of arbitrary programs,
even if full source (or executable) is available.

The proof that such programs *cannot* exist was a simple proof by
contradiction: assume that such a program, P, exists; now run P on
a program Q. Q is a program that finds a certain number by trial
(test each number in turn) when there is no analytic way
to find those kinds of numbers. Add a twist to the program Q such
that once it has found the number, it allocates an amount of memory
equal to the number it has found. Now, in order for P run on Q to
predict how much memory Q will allocate, P would have to be able to
analyze Q and solve what Q would find: only once P knows analytically
the answer to Q can P know how much memory Q would eventually allocate.
However, in order for P to know analytically what Q will do, P
would have to find an analytic way to calculate something that
our premises said does not *have* an analytic solution. Since P
cannot do the impossible, we conclude that program P does not exist.


There are, though -some- programs that can be analyzed for memory use;
there just isn't any way to analyze -every- program.

But you didn't ask for a tool to analyze the memory usage of a
-particular- program, you {implicitly} asked for a tool to analyze
the memory usage of whatever programs you happen to construct. You
were looking for a general analysis tool... and those CANNOT exist
(at least and give the correct answer )
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

Hemal wrote:
>
> I need to know the memory required by a c program. Is there any
> tool/utility which can give me the memory usage in terms of DATA
> segment, TEXT segment, BSS segment etc.
>
> I am working on linux platform and my target is ARM processor.
> But i guess it should not matter. Actually i need to know both
> RAM & ROM usage.

This is system specific, and thus off-topic on c.l.c.
comp.unix.programmer might be able to help. In general you should
look at your system documentation for a way to make the link phase
emit a loadmap.

--
Some informative links:
<news:news.announce.newusers
<http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

Walter Roberson wrote:
> In article <. com>,
> Hemal <> wrote:
> >Thanks for your help but i couldn't make out from what you mean by "odd
> >perfect numbers".
>
> Recapping, the point was that there *cannot* be a program
> which reliably predicts run-time memory usage of arbitrary programs,
> even if full source (or executable) is available.
>
> The proof that such programs *cannot* exist was a simple proof by
> contradiction: assume that such a program, P, exists; now run P on
> a program Q. Q is a program that finds a certain number by trial
> (test each number in turn) when there is no analytic way
> to find those kinds of numbers. Add a twist to the program Q such
> that once it has found the number, it allocates an amount of memory
> equal to the number it has found. Now, in order for P run on Q to
> predict how much memory Q will allocate, P would have to be able to
> analyze Q and solve what Q would find: only once P knows analytically
> the answer to Q can P know how much memory Q would eventually allocate.
> However, in order for P to know analytically what Q will do, P
> would have to find an analytic way to calculate something that
> our premises said does not *have* an analytic solution. Since P
> cannot do the impossible, we conclude that program P does not exist.
>

This is completely off-topic nitpicking, but the odd perfect number
approach is not a real proof. This is a common error in computability
theory: people assume that highly difficult tasks are uncomputable,
which can hardly be further from the truth. There's a famous trick
question, "Let f(x)=1 if God exists, 0 if not. Is f(x) computable?"
The answer is of course "yes" since the constantly 1 function and the
constantly 0 function are both computable and f is one of these.

A correct proof that a general memory-predictor is impossible is more
subtle than meets the eye, because a looping program can, during its
infinite loop, chew up more and more memory, so the trick (which you're
essentially trying to use) of allocating a big block upon halting,
doesn't really work. No matter how big a block we choose, for all we
know the program might chew up precisely that much memory and yet still
not halt, so our memory-predictor sheds no light on the halting problem
that way. Probably the easiest way to prove the program in question is
impossible, is Rice's theorem. Of course it would be nice if someone
can come up with an easier proof, since Rice's theorem is rather
overkill here...

In article <. com>,
Hemal <> wrote:

>Although below question may not belong to this group but in
>continuation to above question

>Is there any difference between RAM & ROM size for same code & if yes
>why? My understanding is ROM size is large as it contains additional
>ReadOnly TEXT section.

That'd be implementation dependant...

ROM can be large; ROM can be small; RAM can be large, RAM can be small.
Some systems have none of one; some have none of the other.

You might have a program that needs a lot of writable memory (RAM) to
do its calculations, even though the code might be small and the
number of constants to look up might be small. For example, it
might calculate the exact value of 3 multiplied by itself a billion
times. Just a lot of repeated calculations.

You might have a program that can do the bulk of its work from static
lookup tables, without needing much working memory. For such a program,
the static tables could be put in ROM and a small RAM used.

Pure ROM systems (no RAM other than CPU registers) can be found in
a few embedded systems such as toasters.

Pure RAM systems, with no ROM (or equivilent) at all, are more
difficult, but can be constructed from "static RAM", "non-volatile RAM",
and similar memory types that are writable but do not lose information
when the power is removed. Failing that, there's always hardware-level
bootstrapping
--
Programming is what happens while you're busy making other plans.

Snis Pilbor wrote:
> Walter Roberson wrote:
> > In article <. com>,
> > Hemal <> wrote:
> > >Thanks for your help but i couldn't make out from what you mean by "odd
> > >perfect numbers".
> >
> > Recapping, the point was that there *cannot* be a program
> > which reliably predicts run-time memory usage of arbitrary programs,
> > even if full source (or executable) is available.
> >
> > The proof that such programs *cannot* exist was a simple proof by
> > contradiction: assume that such a program, P, exists; now run P on
> > a program Q. Q is a program that finds a certain number by trial
> > (test each number in turn) when there is no analytic way
> > to find those kinds of numbers. Add a twist to the program Q such
> > that once it has found the number, it allocates an amount of memory
> > equal to the number it has found. Now, in order for P run on Q to
> > predict how much memory Q will allocate, P would have to be able to
> > analyze Q and solve what Q would find: only once P knows analytically
> > the answer to Q can P know how much memory Q would eventually allocate.
> > However, in order for P to know analytically what Q will do, P
> > would have to find an analytic way to calculate something that
> > our premises said does not *have* an analytic solution. Since P
> > cannot do the impossible, we conclude that program P does not exist.
> >
>
> This is completely off-topic nitpicking, but the odd perfect number
> approach is not a real proof. This is a common error in computability
> theory: people assume that highly difficult tasks are uncomputable,
> which can hardly be further from the truth. There's a famous trick
> question, "Let f(x)=1 if God exists, 0 if not. Is f(x) computable?"
> The answer is of course "yes" since the constantly 1 function and the
> constantly 0 function are both computable and f is one of these.
>
> A correct proof that a general memory-predictor is impossible is more
> subtle than meets the eye, because a looping program can, during its
> infinite loop, chew up more and more memory, so the trick (which you're
> essentially trying to use) of allocating a big block upon halting,
> doesn't really work. No matter how big a block we choose, for all we
> know the program might chew up precisely that much memory and yet still
> not halt, so our memory-predictor sheds no light on the halting problem
> that way. Probably the easiest way to prove the program in question is
> impossible, is Rice's theorem. Of course it would be nice if someone
> can come up with an easier proof, since Rice's theorem is rather
> overkill here...

Ah, upon further consideration, I realized Rice's theorem doesn't even
apply, since this is a question which depends upon the model of
computation, not just the functions themselves.

But I managed to think up a proof.

Theorem: Assuming we're working on an ideal computer with infinite
memory, no program P exists which can predict how much memory an
arbitrary program Q will require.

Proof: Suppose such a program P exists. We'll now solve the halting
problem. Suppose n is an integer, so we need to give an algorithm to
tell whether the program with machine code n, when run on input n, will
halt. Proceed as follows. Write a program Q which simulates the
program with machine code n, with input n, but set it up so the
simulation always invokes twice as much memory as the simulated program
asks for. Also ensure that the simulator itself uses an even number of
bytes for any overhead it needs (even if this means allocating
additional dummy memory). Throughout the simulation, keep track of the
maximum memory required by the simulator at any point so far. If the
simulated program ever halts, then Q will free all memory, and allocate
a block of odd size, and so big that it is bigger than the biggest
amount of memory required hitherto. Now the program with machine code
n, given input n, will halt if and only if Q will require an odd number
of bytes, and we can determine this by plugging Q into P. So we've
solved the halting problem, absurd, therefore no such P exists.