Xref:	news-dnh.mv.net comp.os.msdos.djgpp:3242
Path:	news-dnh.mv.net!mv!news.sprintlink.net!cs.utexas.edu!academ!news.sesqui.net!rice!news!sandmann
From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: GAS (i86) assembling incorectly
Date:	Tue, 14 Nov 1995 16:45:41 CST
Organization:	Rice University, Houston, Texas
Lines:	18
References:	<DI1LHL DOT IMw AT jade DOT mv DOT net>
Reply-To:	sandmann AT clio DOT rice DOT edu
Nntp-Posting-Host:	clio.rice.edu
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway:	from newsgroup comp.os.msdos.djgpp

> A note to everybody:
>   It seems that if you don't specify a opcode suffix, GAS will assemble some 
> instructions with the wrong opperand size and not produce any warnings or 
> error messages! It gleefully assembled "out %al, %dx" into *outw %ax, 

Always review code generated by GAS with a debugger.  It's one of the
buggiest pieces of code I have ever seen.  It does a great job with GCC
output, anything non-C generated (segment overrides, I/O, etc) will 
very likely generate the wrong code.  And typically, if you resorted to
using GAS you needed the constructs it will most frequently mess up.

>   who just spent 3 days debugging before he solved the above problem

Ignored segment overrides and incorrect sizes have cost me at least
200 hours of V2 development time.  Even worse, sometimes segment 
overrides would be generated properly (and sometimes ignored) if you changed 
the *COMMENTS* in the GAS code.  Scary.  Much of V2's GAS code has 
the numeric opcodes added for overrides to work around the bugs. 

- Raw text -