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: Different invariants about the contents of static links


http://earth.google.com/download-earth.html

On 7/13/06, DebianTux23 <wieseltux23@gmail.com> wrote:

http://earth.google.com/download-earth.html




On 07 Jul 2006 10:11:01 -0700, Ian Lance Taylor < iant@google.com> wrote:
> "Rodney M. Bates" < rbatesjk@cox.net> writes:
>
> > The following example  C code and disassembly is compiled by gcc 3.4.3,
> > for i686.  It uses two different invariants for what the value of
> > a static link is.  Everywhere inside P, static link values are consistently
> > the same as base pointer (%ebp) register values for the same activation
> > record.  A static link value is generated at 4c: in P, and used at
> > 22: in PInner2 and c: in PInner1.
> >
> > Everywhere inside similar function Q, static link values consistently point
> > 8 bytes higher than where the base register points.  A value is generated at
>  > d9: in Q and used at 7a: in Qinner2 and 64: in QInner1.
> >
> >  From the examples I have looked at, it looks like it is correct translation,
> > and, expect for seeming strangeness, is not a problem for execution.
> >
> > However, I am working on an extended gdb-derived debugger that works,
> > in part, with code produced by a gcc-derived code generator for
> > Modula-3.  So far, I can't find out, in the debugger, which invariant
> > is in use.  I have the debugger correctly both generating and using
> > static links when evaluating user-typed expressions, using the first
> > invariant.  I could easily change it to use the second invariant, but
> > obviously, that would fix some cases and break others.
> >
> > Is there a compelling reason for this difference?  If not, I would like to
> > make it all use invariant one.  Also, does anybody know where in gcc this
> > difference is happening?  I poked around in the source for a couple of hours,
> > but didn't see anything obvious.
>
> The static link pointer points to a part of the stack frame which
> includes the information required for the nested functions.  The
> amount of information required changes depending on the code.
> Therefore, the static link pointer will not be a constant offset from
> the frame pointer.  I don't believe that it is possible to change this
> while still handling calls between doubly nested functions, but maybe
> I just haven't thought about it hard enough.
>
> > BTW, this is using stabs.  I know that is not very complete, but it would be
> > a lot more work than I want to do to change it.
>
> Stabs doesn't represent the static link pointer at all, so that is
> your problem.  You should switch to DWARF.  If that is impossible as
> you suggest, then I think your most profitable approach would be to
> enhance stabs somehow.
>
> Ian
>




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