public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: James E Wilson <wilson@specifixinc.com>
To: Jan Beulich <JBeulich@novell.com>
Cc: binutils@sources.redhat.com
Subject: Re: [PATCH] ia64 bundle alignment
Date: Fri, 28 Jan 2005 05:05:00 -0000	[thread overview]
Message-ID: <1106888694.18514.260.camel@aretha.corp.specifixinc.com> (raw)
In-Reply-To: <s1f4c515.002@emea1-mh.id2.novell.com>

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


  reply	other threads:[~2005-01-28  5:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-24  9:51 Jan Beulich
2005-01-28  5:05 ` James E Wilson [this message]
2005-01-28  8:04 Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1106888694.18514.260.camel@aretha.corp.specifixinc.com \
    --to=wilson@specifixinc.com \
    --cc=JBeulich@novell.com \
    --cc=binutils@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).