public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: James E Wilson <wilson@tuliptree.org>
To: linux-ia64@vger.kernel.org
Subject: Re: PATCH: Fix 2.6 kernel ia64 directives
Date: Wed, 09 Feb 2005 20:10:13 +0000	[thread overview]
Message-ID: <1107979813.19059.45.camel@aretha.corp.specifixinc.com> (raw)
In-Reply-To: <20050202221918.GA7973@lucon.org>

On Wed, 2005-02-09 at 11:35, David Mosberger wrote:
> Why should it depend on IAS as to whether GAS does or does not produce
> an error?

I was wrong about IAS giving an error in this case (.proc/.endp).  I
mentioned this in an earlier mail.  See Jan's response for the
clarification.

It has always been the goal since the beginning to be compatible with
IAS.  Unfortunately, the gas IA-64 port was never finished.  There is
some stuff that was never implemented, some stuff that was incorrectly
and/or incompletely implemented, and some stuff that is known to be
buggy.  The gas IA-64 port is suffering from a lack of attention. 
Fortunately, there is only one major bug, the DV support is fatally
flawed and has to be rewritten, and at the moment this problem is
limited by the fact that the gcc predication support is not smart enough
to emit code that gas can't handle correctly.

Anyways, these gas problems all need to be fixed eventually.  I do want
to avoid breaking existing code unnecessarily, but it may not be
possible in all cases.

> The fact is that GAS has _not_ in the past issued an error
> and it's not acceptable to break existing code for no good reason.
> Making it a warning is fine, of course.

I believe there is a good reason for this.  We are talking about
directives related to unwind info.  Unwind info only gets tested when
exceptional conditions occur, at which point it is too late to recover. 
It is important that the assembler give an error if a problem is
detected, as otherwise a serious latent bug may go unfixed.  I we give a
warning, then people may not notice it and fix their code.

However, I do understand that there is some inconvenience here.  I have
no problem with emitting a warning temporarily to give people a chance
to migrate.  In fact, I believe I will have to use a warning for now
because these changes break gcc -pg, and this is not easy to fix as it
will also require glibc changes.  I already have a patch from HJ to do
this, I just need to review it.


  parent reply	other threads:[~2005-02-09 20:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-02 22:19 PATCH: Fix 2.6 kernel ia64 directives H. J. Lu
2005-02-02 22:50 ` David Mosberger
2005-02-03  8:12 ` Jan Beulich
2005-02-07 20:11 ` James E Wilson
2005-02-07 22:18 ` James E Wilson
2005-02-09 19:35 ` David Mosberger
2005-02-09 20:05 ` H. J. Lu
2005-02-09 20:10 ` James E Wilson [this message]
2005-02-09 21:11 ` David Mosberger

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=1107979813.19059.45.camel@aretha.corp.specifixinc.com \
    --to=wilson@tuliptree.org \
    --cc=linux-ia64@vger.kernel.org \
    /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