COFF/PE gas regression: bug

[Ian Lance Taylor]

   Date: Tue, 06 Apr 1999 08:51:02 -0600
   From: Donn Terry <donn@interix.com>

   Interesting... I suspect that that explains why the current
   gas is the way it is; whether that's right or not I'm not
   sure yet.  (Clearly, according to the documentation it's
   wrong.)  I'd like to see the results from a System V i386 COFF
   system so we can determine if it's the documentation or
   the Motorola code that's wrong.

The SVR3 implementations are pretty much all the same, since the came
from a common code base.  I'd be very surprised if they differed.

COFF documentation was always completely inadequate.  Don't be
surprised if you see other problems like this.

Moreover, I was moved to check the O'Reilly book on COFF.  It says
that C_MOS, C_MOU and C_MOE symbols are N_ABS.  Here is the table from
the book (table 8-1, p. 100):

C_EXT		N_ABS, N_UNDEF, N_SCNUM
C_AUTO		N_ABS
C_REG		N_ABS
C_LABEL		N_UNDEF, N_SCNUM
C_MOS		N_ABS
C_ARG		N_ABS
C_STRTAG	N_DEBUG
C_MOU		N_ABS
C_UNTAG		N_DEBUG
C_TPDEF		N_DEBUG
C_ENTAG		N_DEBUG
C_MOE		N_ABS
C_REGPARM	N_ABS
C_FIELD		N_ABS
C_BLOCK		N_SCNUM
C_FCN		N_SCNUM
C_EOS		N_ABS
C_FILE		N_DEBUG

According to this book, N_DEBUG is for ``a special symbolic debugging
symbol (an assembler symbolic directive)'' and N_ABS is for ``an
absolute value.''  It expands on that by saying that N_DEBUG ``in
general means that the value has no meaning.''

   (I suspect we'll need some sort of conditional to resolve this
   one, but we'll see.)

Why does it matter?  My understanding is that Microsoft doesn't use
that sort of debugging information, so what program actually cares?

Ian