Stabs Errors Compiling Java Classes
Andrew Haley
aph@redhat.com
Tue Dec 3 10:43:00 GMT 2002
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.
More information about the Java
mailing list