i386 code label alignment patch

[John Wehle]

> > When doing a cross build isn't gas in the build tree?
> Often, but we can not depend on it.

> [ Description of canadian cross build. ]

The intent is not to depend on finding gas.  However, if we do happen
to find the gas which will be used with this gcc, then use any extra
features which happen to be available with this gas.

> OK.  And we know that those platforms use gas and only gas right
> (even if it's an old, busted version -- so long as our configure
> stuff identifies it as some version of gas and provides an appropriate
> definition of the ALIGN macros.

I decided to drop the 386bsd, freebsd, and netbsd changes since they
were slightly risky and didn't have any real advantages.

> We *might* want to provide versions of the ALIGN macros for the case
> when no version of gas was found -- I'm really unsure if we should
> depend on the *bsd* flavors always using gas.

Maybe ... for the moment I'm going with the theory if it ain't broke
then don't fix it.  Currently the default behavior if I can't find or
figure out the version of gas is the same as it's always been.

> Right.   Hmmmm.  How exactly does the configure script determine
> what version of gas is going to be built in the build tree?  Remember
> at configure time in a single tree build gas is not yet built.

Here's the theory (as of version 2):

  1) If there's an executable assembler in the current directory then
     check its version.

  2) Check for VERSION in ../gas/Makefile.in.

  3) If $host == $target then check the version of the assembler in $path.

> I think that the interpretation of the argument to .align is/was
> target dependent.

I was going on the naive belief that gas 1.x only supported bsd. :-)
Upon reflection I decided that it's just not not worth the bother
to try and redefine ASM_OUTPUT_ALIGN properly for gas 1.x.  After
all ... 386bsd.h, freebsd.h, and netbsd.h already handle this issue.

> Ah.  I think it might be better to keep both the desired alignment
> and the maximum "hole size" allowed together in final.c's tables.
> It just seems like a cleaner way to approach the problem.
>
> We'd probably want a single new macro for emitting these new kind
> of alignment directives.  Similarly for a mechanism for the target
> to provide these extra values.

Okay, version 2 of the patch does it this way.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------