Hi Experts,
How can I check the memory regions occupied by the c program in gcc
compiler?
Any commands?
My intention is to check for the variables defined in the
program,whether it is in text,data,stack or heap regions.

Thanks for the help.

In article <ad025df4-921a-4f9d-a051-91c4b6b054c4@z5g2000yqn.googlegroups.com>,
new  <luvraghu@gmail.com> wrote:
>Hi Experts,
>How can I check the memory regions occupied by the c program in gcc
>compiler?
>Any commands?
>My intention is to check for the variables defined in the
>program,whether it is in text,data,stack or heap regions.
>
>Thanks for the help.
>

Beavis/Butthead: He said the "S" word.   Har har har.

new <luvraghu@gmail.com> writes:

> Hi Experts,
> How can I check the memory regions occupied by the c program in gcc
> compiler?
> Any commands?
> My intention is to check for the variables defined in the
> program,whether it is in text,data,stack or heap regions.

....or nowhere.

This is a system-specific question and you will get better help is
group discusses the tools you use.  For example, if you use a
unix-like system, comp.unix.programmer can tell you all about programs
like nm that let you see what the compiler has done with your
program.  There are similar active groups for Windows programming.

-- 
Ben.

On May 28, 5:27=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> new <luvra...@gmail.com> writes:
> > Hi Experts,
> > How can I check the memory regions occupied by the c program in gcc
> > compiler?
> > Any commands?
> > My intention is to check for the variables defined in the
> > program,whether it is in text,data,stack or heap regions.
>
> ...or nowhere.
>
> This is a system-specific question and you will get better help is
> group discusses the tools you use. =A0For example, if you use a
> unix-like system, comp.unix.programmer can tell you all about programs
> like nm that let you see what the compiler has done with your
> program. =A0There are similar active groups for Windows programming.
>
> --
> Ben.

Am trying to find out in Linux machine

new <luvraghu@gmail.com> writes:
> On May 28, 5:27�pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> new <luvra...@gmail.com> writes:
>> > Hi Experts,
>> > How can I check the memory regions occupied by the c program in gcc
>> > compiler?
>> > Any commands?
>> > My intention is to check for the variables defined in the
>> > program,whether it is in text,data,stack or heap regions.
>>
>> ...or nowhere.
>>
>> This is a system-specific question and you will get better help is
>> group discusses the tools you use. �For example, if you use a
>> unix-like system, comp.unix.programmer can tell you all about programs
>> like nm that let you see what the compiler has done with your
>> program. �There are similar active groups for Windows programming.
>
> Am trying to find out in Linux machine

Then try comp.unix.programmer.  If your question turns out to be
Linux-specific, they can direct you to a Linux newsgroup.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson <kst-u@mib.org> writes:

> new <luvraghu@gmail.com> writes:
>> On May 28, 5:27 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>> new <luvra...@gmail.com> writes:
>>> > Hi Experts,
>>> > How can I check the memory regions occupied by the c program in gcc
>>> > compiler?
>>> > Any commands?
>>> > My intention is to check for the variables defined in the
>>> > program,whether it is in text,data,stack or heap regions.
>>>
>>> ...or nowhere.
>>>
>>> This is a system-specific question and you will get better help is
>>> group discusses the tools you use.  For example, if you use a
>>> unix-like system, comp.unix.programmer can tell you all about programs
>>> like nm that let you see what the compiler has done with your
>>> program.  There are similar active groups for Windows programming.
>>
>> Am trying to find out in Linux machine
>
> Then try comp.unix.programmer.  If your question turns out to be
> Linux-specific, they can direct you to a Linux newsgroup.

"Linux machine" seems pretty specific to me. Why would you send him to
the wrong group?

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

Richard wrote:
> "Linux machine" seems pretty specific to me. Why would you send him to
> the wrong group?

Linux is about the most un-specific answer that is possible to be given to the
question about a machine.  Or are you un-aware of how many different distro's
there are?  Most of which do not have groups for them.

To the OP I see you mentioned gcc.  You might check out the gnu.* groups.

On Thu, 28 May 2009 08:01:11 -0700, new wrote:
> On May 28, 5:27�pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> new <luvra...@gmail.com> writes:
>> > Hi Experts,
>> > How can I check the memory regions occupied by the c program in gcc
>> > compiler?
>> > Any commands?
>> > My intention is to check for the variables defined in the
>> > program,whether it is in text,data,stack or heap regions.
>>
>> ...or nowhere.
>>
>> This is a system-specific question and you will get better help is
>> group discusses the tools you use. �For example, if you use a
>> unix-like system, comp.unix.programmer can tell you all about programs
>> like nm that let you see what the compiler has done with your
>> program. �There are similar active groups for Windows programming.
>>
>> --
>> Ben.
> 
> Am trying to find out in Linux machine

Hi new,

You can use nm to find out about variables compiled into your object file
(static/global variables) as Ben said.

At runtime, of course malloc()d variables will be on the heap, local
variables on the stack. One way is to use gdb and set a breakpoint. You
can then type "info frame" to find out the current program counter and
where the locals start. The stack grows down, so look at the address
of the variable youre interested in. If its just below the "locals at"
address from "info frame", its on the stack. If its a much much lower
memory address then its on the heap.

Cheers,
Joe

-- 
       ......................  o    _______________           _,
      ` Good Evening!  ,      /\_  _|             |        .-'_|
      `................,     _\__`[_______________|       _| (_|
                             ] [ \, ][         ][        (_|

kid joe wrote:
> On Thu, 28 May 2009 08:01:11 -0700, new wrote:
>> On May 28, 5:27 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>> new <luvra...@gmail.com> writes:
>>>> Hi Experts,
>>>> How can I check the memory regions occupied by the c program in gcc
>>>> compiler?
>>>> Any commands?
>>>> My intention is to check for the variables defined in the
>>>> program,whether it is in text,data,stack or heap regions.
>>> ...or nowhere.
>>>
>>> This is a system-specific question and you will get better help is
>>> group discusses the tools you use.  For example, if you use a
>>> unix-like system, comp.unix.programmer can tell you all about programs
>>> like nm that let you see what the compiler has done with your
>>> program.  There are similar active groups for Windows programming.
>>>
>>> --
>>> Ben.
>> Am trying to find out in Linux machine
> 
> Hi new,
> 
> You can use nm to find out about variables compiled into your object file
> (static/global variables) as Ben said.
> 
> At runtime, of course malloc()d variables will be on the heap, local
> variables on the stack.

That is inaccurate. Often local variables are only in a register on some 
processors.

> One way is to use gdb and set a breakpoint. You
> can then type "info frame" to find out the current program counter and
> where the locals start. The stack grows down, so look at the address
> of the variable youre interested in. If its just below the "locals at"
> address from "info frame", its on the stack. If its a much much lower
> memory address then its on the heap.

Have you checked on all of the processors Linux have been ported to? No, 
I thought not.

As Ben said, finding a system specific news group (either one of the gnu 
ones, a linux one, or comp.unix.programmer would be better.
-- 
Flash Gordon

"Flash Gordon" <smap@spam.causeway.com> wrote in message 
news:f4j3f6xrbr.ln2@news.flash-gordon.me.uk...
> kid joe wrote:
>> On Thu, 28 May 2009 08:01:11 -0700, new wrote:
>>> On May 28, 5:27 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>>> new <luvra...@gmail.com> writes:
>>>>> Hi Experts,
>>>>> How can I check the memory regions occupied by the c program in gcc
>>>>> compiler?
>>>>> Any commands?
>>>>> My intention is to check for the variables defined in the
>>>>> program,whether it is in text,data,stack or heap regions.
>>>> ...or nowhere.
>>>>
>>>> This is a system-specific question and you will get better help is
>>>> group discusses the tools you use.  For example, if you use a
>>>> unix-like system, comp.unix.programmer can tell you all about programs
>>>> like nm that let you see what the compiler has done with your
>>>> program.  There are similar active groups for Windows programming.
>>>>
>>>> --
>>>> Ben.
>>> Am trying to find out in Linux machine
>>
>> Hi new,
>>
>> You can use nm to find out about variables compiled into your object file
>> (static/global variables) as Ben said.
>>
>> At runtime, of course malloc()d variables will be on the heap, local
>> variables on the stack.
>
> That is inaccurate. Often local variables are only in a register on some 
> processors.
>
>> One way is to use gdb and set a breakpoint. You
>> can then type "info frame" to find out the current program counter and
>> where the locals start. The stack grows down, so look at the address
>> of the variable youre interested in. If its just below the "locals at"
>> address from "info frame", its on the stack. If its a much much lower
>> memory address then its on the heap.
>
> Have you checked on all of the processors Linux have been ported to? No, I 
> thought not.
>
> As Ben said, finding a system specific news group (either one of the gnu 
> ones, a linux one, or comp.unix.programmer would be better.


FWIW, it is almost assured that whatever the OP is using is probably x86, or 
maybe x86-64...
other possibilities are sufficiently unlikely as to be assumed, by default, 
not to be the case.

(or... maybe... one can start making a fuss that these groups are not easily 
accessible to non-English speakers... and the illiterate...).


thus, there is no need to use that sort of attitude when responding...


> -- 
> Flash Gordon 

On May 29, 8:13=A0am, "cr88192" <cr88...@hotmail.com> wrote:
> "Flash Gordon" <s...@spam.causeway.com> wrote in message
> news:f4j3f6xrbr.ln2@news.flash-gordon.me.uk...
> > kid joe wrote:
> >> On Thu, 28 May 2009 08:01:11 -0700, new wrote:
> >>> On May 28, 5:27 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >>>> new <luvra...@gmail.com> writes:
> >>>>> Hi Experts,
> >>> Am trying to find out in Linux machine
> >> Hi new,
> >> You can use nm ...
> > That is inaccurate. ... on some
> > processors.
> > Have you checked on all of the processors Linux
> > have[sic] been ported to? No, I
> > thought not.
>
> FWIW, it is almost assured that whatever the OP is
> using is probably x86, or maybe x86-64...
> other possibilities are sufficiently unlikely as to be
> assumed, by default, not to be the case.

Note moreover, that the chance OP is not using
x86 is even smaller than the (small) a priori chance.
This is because even a relatively naive user would
be aware any non-x86 machine is somewhat "unusual"
and therefore would have mentioned it.

In the (unlikely) event that further evidence were
needed of excessive pedantry in c.l.c, these continual
topicality debates would prove it!

Although in this case c.u.p might be a good bet,
some of the ng recommendations here are often absurd,
of a ng with a name that makes it appear topical
but which is actually devoted to discussions about
sodomizing pigs, or some such.

James

cr88192 wrote:
> "Flash Gordon" <smap@spam.causeway.com> wrote in message 
> news:f4j3f6xrbr.ln2@news.flash-gordon.me.uk...
>> kid joe wrote:
>>> On Thu, 28 May 2009 08:01:11 -0700, new wrote:
>>>> On May 28, 5:27 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>>>> new <luvra...@gmail.com> writes:
>>>>>> Hi Experts,
>>>>>> How can I check the memory regions occupied by the c program in gcc
>>>>>> compiler?
>>>>>> Any commands?
>>>>>> My intention is to check for the variables defined in the
>>>>>> program,whether it is in text,data,stack or heap regions.
>>>>> ...or nowhere.
>>>>>
>>>>> This is a system-specific question and you will get better help is
>>>>> group discusses the tools you use.  For example, if you use a
>>>>> unix-like system, comp.unix.programmer can tell you all about programs
>>>>> like nm that let you see what the compiler has done with your
>>>>> program.  There are similar active groups for Windows programming.
>>>>>
>>>>> --
>>>>> Ben.
>>>> Am trying to find out in Linux machine
>>> Hi new,
>>>
>>> You can use nm to find out about variables compiled into your object file
>>> (static/global variables) as Ben said.
>>>
>>> At runtime, of course malloc()d variables will be on the heap, local
>>> variables on the stack.
>> That is inaccurate. Often local variables are only in a register on some 
>> processors.
>>
>>> One way is to use gdb and set a breakpoint. You
>>> can then type "info frame" to find out the current program counter and
>>> where the locals start. The stack grows down, so look at the address
>>> of the variable youre interested in. If its just below the "locals at"
>>> address from "info frame", its on the stack. If its a much much lower
>>> memory address then its on the heap.
>> Have you checked on all of the processors Linux have been ported to? No, I 
>> thought not.
>>
>> As Ben said, finding a system specific news group (either one of the gnu 
>> ones, a linux one, or comp.unix.programmer would be better.
> 
> FWIW, it is almost assured that whatever the OP is using is probably x86, or 
> maybe x86-64...
> other possibilities are sufficiently unlikely as to be assumed, by default, 
> not to be the case.

I agree that it is the most likely, but it is by no means the only 
processor hobiest are using Linux on. It is also used in the old non-x86 
Macs and the last time I checked the TiVo (for which there certainly 
used to be a large hacking community).

> (or... maybe... one can start making a fuss that these groups are not easily 
> accessible to non-English speakers... and the illiterate...).

I do not see what that has got to do with it.

> thus, there is no need to use that sort of attitude when responding...

The post did not says something like, "on the x86 which you are probably 
using..." and was also in direct response to a post which suggested a 
more appropriate group for the discussion. So I do think that pointing 
out that not all the world is an x86 and that more appropriate groups 
had been suggested was appropriate.
-- 
Flash Gordon

In article <107103f3-7c03-4cad-9621-3b48897467c2@b1g2000vbc.googlegroups.com>,
James Dow Allen  <jdallen2000@yahoo.com> wrote:
....
>Although in this case c.u.p might be a good bet,
>some of the ng recommendations here are often absurd,
>of a ng with a name that makes it appear topical
>but which is actually devoted to discussions about
>sodomizing pigs, or some such.

Kewl!

Note that this is true of CLC itself, as well.

I.e., although a superficial analysis might conclude that this is
a newsgroup for dicussion of C programming, in fact, nothing could be
further from the truth.  Any discussion of real C programming is, of
course, off-topic - and will draw a quick rebuke from those in control.
But discussions of just about everything and anything else, such as
Fortran compilers, PL/1 compilers, Shakespeare, English history, the
correct and proper term to use to refer to residents of the United
States of America, dirty underwear, data structures (Just make sure to
avoid using the "S word" when doing so!), the histories (and relative
market shares over time) of computer companies, and so on, is all OK and
will get nary a comment from the "mods".

In article <gvncr3$pf4$1@news.albasani.net>,
cr88192 <cr88192@hotmail.com> wrote:
....
>FWIW, it is almost assured that whatever the OP is using is probably
>x86, or maybe x86-64...  other possibilities are sufficiently unlikely
>as to be assumed, by default, not to be the case.

Indeed.  Quite.

>(or... maybe... one can start making a fuss that these groups are not
>easily accessible to non-English speakers... and the illiterate...).

Not quite sure what you mean by this.

>thus, there is no need to use that sort of attitude when responding...

It's what they live for.  For many of them, it is quite literally, their
only reason to get out of bed each day.

cr88192 wrote:
> 
> FWIW, it is almost assured that whatever the OP is using is probably x86, or 
> maybe x86-64...
> other possibilities are sufficiently unlikely as to be assumed, by default, 
> not to be the case.

	THE TENTH COMMANDMENT:
	Thou shalt foreswear, renounce, and abjure the vile heresy
	which claimeth that ``All the world's a VAX'', and have no
	commerce with the benighted heathens who cling to this barbarous
	belief, that the days of thy program may be long even though the
	days of thy current machine be short.

	Learned commentary thereon:
	This particular heresy bids fair to be replaced by ``All the
	world's a Sun'' or ``All the world's a 386'' (this latter being
	a particularly revolting invention of Satan), but the words
	apply to all such without limitation. Beware, in particular, of
	the subtle and terrible ``All the world's a 32-bit machine'',
	which is almost true today but shall cease to be so before thy
	resume grows too much longer.

     Go, and sin no more.

-- 
Eric.Sosman@sun.com