Let me quickly introduce myself, and then get on to the topic: I'm Donn Terry, and over the last several years I've been working on the Interix port of the FSF compiler tools (the whole chain, from gcc/egcs thru gdb). I'm now in the process of actively remerging those changes into the official trees, maintainers approving. I'll be working with PE/PEI format stuff, both Intel and Alpha. I've been in contact with Ian and DJ about this. (Yes, I really started with Cygwin stuff.) In the process of doing the Gas port, I've run into something that both the gas2 and bfd lists may wish to discuss, so I'm sending to both (realizing that there may not be much difference between the two.) (And for archive purposes.) I believe the gas testsuite has a bad test, as follows: In testsuite/gas/all/gas.exp, one of the tests is for structure tags (see cofftag*). It creates the symbol _operator as storage class 16 (MOE), type 11 (0xb, MOE). According to the best COFF standard I have (which is no longer on the web that I can find, but was on SCO's website): "A special section number (-2) marks symbolic debugging symbols, including structure/union/enumeration tag names...". (Microsoft's PE documentation agrees, but isn't quite as explicit.) (DJ's machine is not responding at the moment.) The test expects a value of -1 (Absolute symbol), which according to the above is incorrect. I've a fix for this (as part of a larger bundle of fixes), but since it's a visible incompatability, I thought I'd check if anyone cared (either way). (The fix actually affects more than just MOE, obviously, but it follows the standards to the best I can interpret them.) There's more along this line (inconsistencies between the COFF/PE "standards" and the FSF tools); if you in general care about COFF/PE, please respond and I'll collect a "those who care" list about other such items. (DJ, Ian, don't bother; you can't escape :-) !) Donn -- =================================================== Donn Terry mailto:donn@interix.com Softway Systems, Inc. http://www.interix.com 2850 McClelland Dr, Ste. 1800 Ft.Collins CO 80525 Tel: +1-970-204-9900 Fax: +1-970-204-9951 ===================================================
Date: Wed, 31 Mar 1999 10:17:55 -0700 From: Donn Terry <donn@interix.com> I believe the gas testsuite has a bad test, as follows: In testsuite/gas/all/gas.exp, one of the tests is for structure tags (see cofftag*). It creates the symbol _operator as storage class 16 (MOE), type 11 (0xb, MOE). According to the best COFF standard I have (which is no longer on the web that I can find, but was on SCO's website): "A special section number (-2) marks symbolic debugging symbols, including structure/union/enumeration tag names...". (Microsoft's PE documentation agrees, but isn't quite as explicit.) (DJ's machine is not responding at the moment.) The test expects a value of -1 (Absolute symbol), which according to the above is incorrect. The best approach for something like this is to see what the tools on some other COFF system do. Can anybody try assembling gas/testsuite/gas/all/cofftag.s on a native COFF system? Ian
Given the enthusiastic(?) response over the last most-of-a-week, I think it's reasonable to conclude that there isn't much interest left in "ordinary" COFF. (I won't go so far as "none", because I'm sure there are interested folks who aren't on this list.) I'm not sure whether that makes things harder or easier; the lack of a comparison base will definitely make things harder. (I have someone within Softway who thinks they may be able to come up with something, but until it happens, it hasn't happened :-) ). Donn Ian Lance Taylor wrote: > > Date: Wed, 31 Mar 1999 10:17:55 -0700 > From: Donn Terry <donn@interix.com> > > I believe the gas testsuite has a bad test, as follows: In > testsuite/gas/all/gas.exp, one of the tests is for structure tags > (see cofftag*). It creates the symbol _operator as > storage class 16 (MOE), type 11 (0xb, MOE). According to > the best COFF standard I have (which is no longer on > the web that I can find, but was on SCO's website): > "A special section number (-2) marks symbolic debugging symbols, > including structure/union/enumeration tag names...". > (Microsoft's PE documentation agrees, but isn't quite as > explicit.) (DJ's machine is not responding at the moment.) > > The test expects a value of -1 (Absolute symbol), which according > to the above is incorrect. > > The best approach for something like this is to see what the tools on > some other COFF system do. Can anybody try assembling > gas/testsuite/gas/all/cofftag.s on a native COFF system? > > Ian -- =================================================== Donn Terry mailto:donn@interix.com Softway Systems, Inc. http://www.interix.com 2850 McClelland Dr, Ste. 1800 Ft.Collins CO 80525 Tel: +1-970-204-9900 Fax: +1-970-204-9951 ===================================================
> > Can anybody try assembling
> > gas/testsuite/gas/all/cofftag.s on a native COFF system?
Here it is (on m68k-motorola-sysv). I have regenerated cofftag.s with my
native compiler, because my native assembler refused to assemble cofftag.s
from the testsuite.
---------------------------- cofftag.s -----------------------------------
file "cofftag.c"
data 1
global token
token:
short 0x0000
text
def token; scl 15; type 012; size 4; endef
def operator; val 0; scl 16; type 013; endef
def flags; val 1; scl 16; type 013; endef
def ~eos; val 4; scl 102; tag token; size 4; endef
data 1
even
global what
what:
long 0
--------------------------------------------------------------------------
and here are the result of the native `nm' and of objdump --syms
phdm/mac_tst nm cofftag.o
Symbols from cofftag.o:
Name Value Class Type Size Line Section
cofftag.c | | file | | | |
token | |entag | enum| 4| |
operator | 0|enmem | enmem| | |(ABS)
flags | 1|enmem | enmem| | |(ABS)
.eos | |endstr| null| 4| |(ABS)
token | 0|extern| null| | |.data
what | 2|extern| null| | |.data
phdm/mac_tst objdump --syms -a cofftag.o
cofftag.o: file format coff-m68k
cofftag.o
SYMBOL TABLE:
[ 0](sec -2)(fl 0x00)(ty 0)(scl 103) (nx 1) 0x00000000 cofftag.c
File
[ 2](sec -2)(fl 0x00)(ty a)(scl 15) (nx 1) 0x00000000 token
AUX lnno 0 size 0x4 tagndx 0 endndx 8
[ 4](sec -1)(fl 0x00)(ty b)(scl 16) (nx 0) 0x00000000 operator
[ 5](sec -1)(fl 0x00)(ty b)(scl 16) (nx 0) 0x00000001 flags
[ 6](sec -1)(fl 0x00)(ty 0)(scl 102) (nx 1) 0x00000004 .eos
AUX lnno 0 size 0x4 tagndx 2
[ 8](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .text
AUX scnlen 0x0 nreloc 0 nlnno 0
[ 10](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .data
AUX scnlen 0x8 nreloc 0 nlnno 0
[ 12](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000008 .bss
AUX scnlen 0x0 nreloc 0 nlnno 0
[ 14](sec 2)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 token
[ 15](sec 2)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000002 what
The section number used is -1, not -2. I still hope this helps.
Philippe
Thanks. 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. (I suspect we'll need some sort of conditional to resolve this one, but we'll see.) Donn =================================================== Donn Terry mailto:donn@interix.com Softway Systems, Inc. http://www.interix.com 2850 McClelland Dr, Ste. 1800 Ft.Collins CO 80525 Tel: +1-970-204-9900 Fax: +1-970-204-9951 ===================================================
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
> Why does it matter? My understanding is that Microsoft doesn't use > that sort of debugging information, so what program actually cares? I don't remember *yet*. I made a lot of these changes quite some time ago, and I suspect I ran across something that forced me to look at it more deeply. I'll hold the patch until I can make the case for it (which may be never.) Consider the topic dropped for now. Donn -- =================================================== Donn Terry mailto:donn@interix.com Softway Systems, Inc. http://www.interix.com 2850 McClelland Dr, Ste. 1800 Ft.Collins CO 80525 Tel: +1-970-204-9900 Fax: +1-970-204-9951 ===================================================