ia64 gas default mode

Jan Beulich JBeulich@novell.com
Thu Jan 20 07:56:00 GMT 2005


Thanks for this detailed explanation. It in parituclar also hints at why
I, within the first few hours of trying to use gas to translate assembly
sources, ran into so many (non-DV-related) problems that I didn't even
get to see many DV-related ones, yet. I hope to be able to provide
patches for most/all of them within a few days...

Nevertheless, the whole thing worries me when I'm thinking of both
using gas for translating actual assembly sources (immediately) as well
as (mid-term) getting gcc to make better use of predication (and other
hardware features). I would hope that I don't have to switch back to
using the Intel assembler, in part because it's not available as cross
assembler for Linux.

Jan

>>> James E Wilson <wilson@specifixinc.com> 20.01.05 01:05:52 >>>
On Wed, 2005-01-19 at 01:38, Jan Beulich wrote:
> c-ia64.texi says that dependency violation checking is being turned
on
> by default...

As for the docs, the IA-64 port was contributed in April 2000 without
docs.  In February 2002, David Mosberger contributed a patch to fix a
problem with some options, Nick Clifton pointed out that we were
lacking
docs, and so David threw some together as a starting point.  David got
the documentation wrong for -x at this point.  Perhaps because gcc
defaults to passing -x to the assembler?  You were the first to notice
the mistake.  See the thread that ends at
	http://sources.redhat.com/ml/binutils/2002-02/msg00826.html 
It would be trivial to correct the docs to match the source code if
that
is what you want.

As for why the DV checking support behaves strangely, this is more
complicated.  There are a number of problems here.  Two in particular
are:
1) Ideally, the assembler/compiler should have been implemented before
end users started using it.  Unfortunately, Intel started a kernel
project before they started an assembler/compiler project, so we were
forced into the position of providing something minimal that worked
for
kernel development, and then fixing it to be correct later.  This
caused
a number of problems with development, one of which was with the DV
checking support.  The original assembler had no DV checking support
at
all; this had to be added in later without breaking kernel
development,
and that constrained what we could do.
2) The DV checking support turns out to be far more complicated than
anyone thought.  What it does is very straight forward, but once you
start implementing it, you discover that there are so many special
cases
to get right that it is a nightmare to implement correctly.  The
current
gas DV checking support has serious bugs that can not be fixed.  It
needs to be ripped out and replaced with a better implementation.  I
have a plan for how to do this, but I estimate that it will take me
1-man month.  IA-64 work is a hobby for me.  This isn't something that
I
can easily do in my spare time on weekends.  And this work is probably
2-man months if done by someone else, who doesn't already have a good
understanding of all of the pitfalls.  It isn't clear when this will
get
fixed.  The only positive part of this is that the gcc predication
support is so limited that gcc isn't smart enough to generate any of
the
problematic cases that the assembler doesn't handle correctly.  So if
you don't have any asms, it will be very rare for you to see an
assembler DV problem when compiling code.  If gcc ever gets smarter,
this assembler problem will become much more serious.

So here is the situation, we have DV checking support, but it is known
to have bugs that can't be fixed.  Sometimes, it reports problems that
aren't real.  Sometimes, it fails to find problems that are real.  We
need to work around these problems some how.

One thing we do is that we emit warnings instead of errors.  Ideally,
if
we find a provable DV, then we should emit an error.  However, if we
do
emit an error, then some valid programs will fail to assemble, and
some
valid programs will fail to compile, and the user will be stuck.  So
instead we emit warnings, and if the assembler is wrong, then you can
still get object code.  If and when the DV support is fixed, these
warnings for provable DVs should be turned into errors.  Warning for
suspected but not provable DVs should remain warnings.

The other issue is what to do by default.  If we enable the DV support
by default, then that means some programs might be broken when the
assembler detects a false DV and tries to correct.  So we have three
choices here:
1) Do nothing.  Assembly programs with correct stop bits will always
work.  Assembly programs without correct stop bits will not work, and
the user won't be told anything is wrong, unless a -x option is used.
2) Enable -xauto by default.  Assembly programs with correct stop bits
will almost always work, but a few may be incorrectly assembled. 
Assembly programs without correct stop bits will almost always work,
but
a few may be incorrect assembled.
3) Enable -xexplicit by default.  Assembler programs with correct stop
bits will always work, but a few may get false DV warnings.  Assembler
programs without correct stop bits will never work, and most but not
all
will get assembler warnings.

Now the question is, which is the lesser of three evils?  I would
argue
that 3 is the least worst choice, even though it is different from the
Intel assembler default.  I don't think 2 will be a practical choice
until the gas DV checking support is fixed.

So I'd suggest that we fix the source code to match the docs here.

Another point to keep in mind that there may be assumptions in linux
kernel and/or glibc about how the assembler DV support works.  So if
we
make changes to gas, we will need to check to make sure we don't
accidentally break the linux kernel and/or glibc.  I think both
default
to using -x (-xexplicit) in ASFLAGS, so there is probably no problem
here.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com 




More information about the Binutils mailing list