[PATCH] ia64 bundle alignment

[Jan Beulich]

OK, I can accept that. I just tried to get this in line with the Intel
assembler; I didn't intend to put data in a function myself... Jan

>>> James E Wilson <wilson@specifixinc.com> 28.01.05 06:04:55 >>>
On Mon, 2005-01-24 at 01:51, Jan Beulich wrote:
> With mixed code and data emission, bundles could be misaligned.
While
> there
> appearantly was a previous attempt to address this (producing an
error
> in
> such a case)

I left this one for last because I don't like it.  You shouldn't be
mixing code and data in ia64 assembly language.  It just causes too
much
trouble.  It can be made to work in some restricted cases if you know
what you are doing, but not in general, and hence I don't think we
should be encouraging it by making it easier.  If anything, we should
be
emitting more warnings for your example.  IMHO, you shouldn't be
putting
data between proc and endp.  The data isn't part of the function.

It is trivial to make your examples work by adding .align directives
to
your code.  I think that is the right solution in this case.

I understand that the Intel assembler is more permissive than GNU as
here, but the Intel assembler is broken.  It will accept some stuff
that
can't possibly work, and then produce bad object files for you without
giving you any warning or error.  I don't want GNU as to do that.

I'd suggest using xdata directives instead of data directives.  This
allows you to put the data directives within a function, without
actually mixing code and data.

Also, don't ever use .section directives inside a function.  This
breaks
DV checking.  We try to make it work by emitting padding nops and a
stop
bit, but if you need serialization, you are screwed.  This is so
difficult to get right that I don't think we should even be trying. 
Instead, I think we should be discouraging section switches inside
functions, and similarly emitting data inside functions.

Besides the question of whether we should support this, there is also
an
efficiency issue.  Calling frag_align will create a variant frag. 
This
means we will end up with two frags for every instruction bundle. 
This
will force the assembler to do a lot more work than it currently does,
just to support something people shouldn't be doing in the first place.

This doesn't make much sense.  I think it makes more sense to ask you
to
add .align directives to your code.

Also, historically, we have had problems with variant frags.  HJ fixed
the unwind info generation last year.  The generation of the unwind
info
has to be delayed until after relaxation.  Before this was done, we
would get incorrect unwind info when variant frags for alignment were
present.  There could also be other hidden problems.  I'd prefer to
avoid generating unnecessary variant frags.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com