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: [tree-ssa] Java: Decls that alias?


Jeff Sturm writes:
 > On Tue, 16 Sep 2003, Andrew Haley wrote:
 > >  > Andrew, I'm not sure I really understand the problem.  Is this somehow
 > >  > related to the bytecode failures currently on tree-ssa?
 > >
 > > I think so.
 > >
 > > Imagine you have "Slot 4", and this contains a jint.
 > >
 > > At one point in the program, "Slot 4" might have debug info with a
 > > variable name "bar".  At another point, "Slot 4" might have debug info
 > > with a variable name "foo".  But semantically they are the same
 > > variable -- an assignment to "Slot 4" can refer either to "foo" or
 > > "bar".  So, we need to treat "foo" and "bar" as two names of a single
 > > variable.
 > 
 > I see.  So this only matters if you have debug info and wish to generate
 > debug info in the object file?  Otherwise you can create one decl for each
 > slot (or pair of slots, for a long/double) and be done with it.

Correct.

 > > Also, at some point in the program there might be no debug info at all
 > > for "Slot 4", yet it's still legal to refer to that slot.  A write to
 > > "Slot 4" might be read later as "foo" or "bar".
 > 
 > I'd guess this is legal in the sense that the bytecode verifier
 > ignores LocalVariableTable attributes?  It doesn't sound like
 > reasonable behavior for any compiler, legal or not.

Reasonable?  Maybe not.  But it's quite common for debugging info not
to start until after the first assignment of a variable.

 > > We handle this in the current byte compiler by sharing RTL between all
 > > the decls that correspond to "Slot 4".
 > 
 > I'd think it would be cleaner to keep one decl per slot.  But then I don't
 > know how you'd get the debug info right, unless you place all the aliasing
 > decls in an anonymous union.

That's a possibility.

 > I wonder what Fortran will do for the EQUIVALENCE keyword.  The g77 docs
 > seem to say it doesn't emit debug info at all for these.

Or C++ for "int &a = b".

 > Do you think users really care much about symbolic debugging when
 > compiling class files?

Oh yes.  People here at Red Hat care very much indeed.

 > I presume they'd only need it when they don't have source code, in
 > which case the symbolic debug info is only marginally useful
 > anyhow.

We have used the dubug info to find bugs in the bytecode compiler,
amongst other things.  I'm going to look at anonymous unions.

I want gcj-as-jit to work well, and good debug info is part of that.

Andrew.


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