Re: Stabs Errors Compiling Java Classes

[Ranjit Mathew <rmathew at hotmail dot com>]

Andrew Haley wrote:
> Ranjit Mathew writes:
>  > Andrew Haley wrote:
>  > > Ranjit Mathew writes:
>  > >  > Tom Tromey wrote:
>  > >  > > Ranjit> 4. description - can be any *16-bit, unsigned value*.
>  > >  > > Ranjit>     (Used for storing line numbers when using GNU debug
>  > >  > > Ranjit>     extensions. Hence a limit of 65535 lines for the
>  > >  > > Ranjit>     source code if stabs debug info is to be used.)
>  > >  > > 
>  > >  > > Ok, I think I can explain.  In gcj we keep track of both line and
>  > >  > > column numbers by packing them in to (I believe) a single 32-bit
>  > >  > > value.  Perhaps this is not being properly decoded before it is passed
>  > >  > > to the debug info generator.  That's an area I really know very little
>  > >  > > about.
>  > >  > 
>  > >  > The GCC "tree.h" header file defines EXPR_WFL_* macros that
>  > >  > encapsulate this behaviour - it would seem by looking at the
>  > >  > definition of these macros that line/col. info is packed
>  > >  > in a 20+12 bits packed format respectively, for Java.
>  > >  > 
>  > >  > However, in dbxout.c (dbxout_finish_symbol), I've had to
>  > >  > right shift the packed value *16-bits* to the right to get a
>  > >  > sane value! Some real SNAFU seems to be happening in there...
>  > > 
>  > > SNAFU?  I don't think so.  See this:
>  > > 
>  > > /* Retrieve those two info separately. */
>  > > #define DECL_SOURCE_LINE_FIRST(DECL)    (DECL_SOURCE_LINE(DECL) & 0x0000ffff)
>  > > #define DECL_SOURCE_LINE_LAST(DECL)     (DECL_SOURCE_LINE(DECL) >> 16)
>  > 
>  > Thanks for pointing that out - that explains the "interesting"
>  > observation in my last mail. In dbxout.c, I should really just
>  > get the *lower 16-bits* for the first line of the function.
>  > 
>  > However, I still think there's a SNAFU - why is this
>  > encoded line number being passed as is to the back end?
>  > The stabs debugging info generator (dbxout.c) certainly
>  > seems to be unaware of this encoding. Aren't other
>  > debugging formats confused by it?
>
> They're not confused, no, because DWARF unsigned integer attributes
> are of type unsigned long.  However, IMO the information is incorrect,
> as you say.
>
>  > And why are there *two* ways of encoding line number
>  > information for decl-s - the EXPR_WFL_XXX 20+12 bit
>  > line no./col. no. way (gcc/tree.h) and the
>  > DECL_SOURCE_LINE_MERGE 16+16 end/begin line no. way
>  > (gcc/java/parse.h)? And they both seem to be using the
>  > DECL_SOURCE_LINE( ) of a decl... Somewhat confusing for
>  > a "nooB"!
>
> No.  See:
>
>
> #define EXPR_WFL_SET_LINECOL(NODE, LINE, COL) \
>   (EXPR_WFL_LINECOL(NODE) = ((LINE) << 12) | ((COL) & 0xfff))
>
> #define EXPR_WFL_LINECOL(NODE) (EXPR_CHECK (NODE)->exp.complexity)
>
> #define DECL_SOURCE_LOCATION(NODE) (DECL_CHECK (NODE)->decl.locus)
> #define DECL_SOURCE_LINE(NODE) (DECL_SOURCE_LOCATION (NODE).line)
>
>
> Try setting DECL_SOURCE_LINE = DECL_SOURCE_LINE_FIRST in
> source_end_java_method() before calling rest_of_compilation().
Yes, that seems to work well. Will you please modify it accordingly?

Or would you like me to submit a patch or open a PR for this?

Ranjit.

--
Ranjit Mathew        Email: rmathew AT hotmail DOT com
Bangalore,
INDIA.               Web: http://ranjitmathew.tripod.com/