Re: Stabs Errors Compiling Java Classes

[Ranjit Mathew <rmathew at hotmail dot com>]

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?

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"!

Or am I missing something yet again? :-(

Sincerely Yours,
Ranjit.

--
Ranjit Mathew          Email: rmathew AT hotmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/