This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Stabs Errors Compiling Java Classes
- From: Ranjit Mathew <rmathew at hotmail dot com>
- To: java at gcc dot gnu dot org
- Date: Tue, 03 Dec 2002 23:54:37 +0530
- Subject: Re: Stabs Errors Compiling Java Classes
- References: <as37j2$900$1@main.gmane.org> <as4n7k$k6d$1@main.gmane.org> <87isyhi7fg.fsf@fleche.redhat.com>
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...
BTW, for method definitions, the line number seems to be the
line number of the *closing brace* for the function definition.
"Interesting".
In any case, I've managed to get rid of the assembler stabs
warning messages for now. :-|
Sincerely Yours,
Ranjit.
--
Ranjit Mathew Email: rmathew AT hotmail DOT com
Bangalore,
INDIA. Web: http://ranjitmathew.tripod.com/