This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] ia64 bundle alignment


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]