This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Interpreting stack frame


Peter Leist wrote:
> On Fri, Mar 20, 2009 at 4:54 PM, Ian Lance Taylor <iant@google.com> wrote:
>> Peter Leist <peterleist@googlemail.com> writes:
>>
>>> How can I interpret the stack frame of the current_function? That
>>> means, how can
>>> I tell what is stored at the location FP+xxx. If that is not (easily)
>>> possible, it would
>>> help if I can somehow determine the type of data stored at that
>>> location (i.g is that
>>> a reference to a variable or the contents of a variable).
>> Stack slots can be shared by different variables, so I'm not sure there
>> is a coherent answer to this.
> 
> I understand that, but at a given point in the program flow the assignment
> of stack slot to a variable should be fixed.

Should it?  We do some very drastic transformations in gcc, sometimes
coalescing variables, sometimes eliminating them altogether, and
sometimes creating new ones which have no equivalent in the source.
This is all business as usual for an optimizing compiler.

> What I try to achieve is: Given the frame pointer for a function X, how can I
> tell which of the used stack frames hold what data (at a given time in
> the program flow).
> To be more exact, I would like to know that before a call is taken. I want to
> tell for every stack slot of the *calling* function if the data in that slot is
> passed to the called function as a reference or not....
> 
> Every debugger should be able to tell that, or am I wrong? Can I probably
> extract the information from debug data?

Yes, but as I explain above the information is not going to be complete.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]