http://earth.google.com/download-earth.html
On 7/13/06, DebianTux23 <[EMAIL PROTECTED]> wrote:
http://earth.google.com/download-earth.html On 07 Jul 2006 10:11:01 -0700, Ian Lance Taylor < [EMAIL PROTECTED]> wrote: > "Rodney M. Bates" < [EMAIL PROTECTED]> 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 >
