public inbox for bfd@sourceware.org
 help / color / mirror / Atom feed
* COFF/PE gas regression: bug
@ 1999-03-31  9:21 Donn Terry
  1999-03-31 10:24 ` Ian Lance Taylor
  0 siblings, 1 reply; 7+ messages in thread
From: Donn Terry @ 1999-03-31  9:21 UTC (permalink / raw)
  To: bfd, gas2

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
===================================================

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: COFF/PE gas regression: bug
  1999-03-31  9:21 COFF/PE gas regression: bug Donn Terry
@ 1999-03-31 10:24 ` Ian Lance Taylor
  1999-04-05  8:31   ` Donn Terry
  0 siblings, 1 reply; 7+ messages in thread
From: Ian Lance Taylor @ 1999-03-31 10:24 UTC (permalink / raw)
  To: donn; +Cc: bfd, gas2

   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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: COFF/PE gas regression: bug
  1999-03-31 10:24 ` Ian Lance Taylor
@ 1999-04-05  8:31   ` Donn Terry
  1999-04-05 16:22     ` Philippe De Muyter
  0 siblings, 1 reply; 7+ messages in thread
From: Donn Terry @ 1999-04-05  8:31 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: bfd, gas2

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
===================================================

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: COFF/PE gas regression: bug
  1999-04-05  8:31   ` Donn Terry
@ 1999-04-05 16:22     ` Philippe De Muyter
  1999-04-06  7:55       ` Donn Terry
  0 siblings, 1 reply; 7+ messages in thread
From: Philippe De Muyter @ 1999-04-05 16:22 UTC (permalink / raw)
  To: Donn Terry; +Cc: ian, bfd, gas2

> > 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: COFF/PE gas regression: bug
  1999-04-05 16:22     ` Philippe De Muyter
@ 1999-04-06  7:55       ` Donn Terry
  1999-04-06  8:11         ` Ian Lance Taylor
  0 siblings, 1 reply; 7+ messages in thread
From: Donn Terry @ 1999-04-06  7:55 UTC (permalink / raw)
  To: Philippe De Muyter, bfd, gas2

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
===================================================

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: COFF/PE gas regression: bug
  1999-04-06  7:55       ` Donn Terry
@ 1999-04-06  8:11         ` Ian Lance Taylor
  1999-04-06  8:20           ` Donn Terry
  0 siblings, 1 reply; 7+ messages in thread
From: Ian Lance Taylor @ 1999-04-06  8:11 UTC (permalink / raw)
  To: donn; +Cc: phdm, bfd, gas2

   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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: COFF/PE gas regression: bug
  1999-04-06  8:11         ` Ian Lance Taylor
@ 1999-04-06  8:20           ` Donn Terry
  0 siblings, 0 replies; 7+ messages in thread
From: Donn Terry @ 1999-04-06  8:20 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: phdm, bfd, gas2

> 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
===================================================

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~1999-04-06  8:20 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-03-31  9:21 COFF/PE gas regression: bug Donn Terry
1999-03-31 10:24 ` Ian Lance Taylor
1999-04-05  8:31   ` Donn Terry
1999-04-05 16:22     ` Philippe De Muyter
1999-04-06  7:55       ` Donn Terry
1999-04-06  8:11         ` Ian Lance Taylor
1999-04-06  8:20           ` Donn Terry

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).