Re: Stabs Errors Compiling Java Classes

[Andrew Haley <aph at redhat dot com>]

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)

in java/parse.h.

Andrew.