From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Lance Taylor To: donn@interix.com Cc: phdm@macqel.be, bfd@cygnus.com, gas2@cygnus.com Subject: Re: COFF/PE gas regression: bug Date: Tue, 06 Apr 1999 08:11:00 -0000 Message-id: <19990406151131.15260.qmail@comton.airs.com> References: <370A1F56.3DD2541F@interix.com> X-SW-Source: 1999/msg00072.html Date: Tue, 06 Apr 1999 08:51:02 -0600 From: Donn Terry 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