From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22472 invoked by alias); 20 Jan 2005 07:56:09 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 22410 invoked from network); 20 Jan 2005 07:55:55 -0000 Received: from unknown (HELO emea1-mh.id2.novell.com) (195.33.99.129) by sourceware.org with SMTP; 20 Jan 2005 07:55:55 -0000 Received: from EMEA1-MTA by emea1-mh.id2.novell.com with Novell_GroupWise; Thu, 20 Jan 2005 07:55:54 +0100 Message-Id: Date: Thu, 20 Jan 2005 07:56:00 -0000 From: "Jan Beulich" To: Cc: Subject: Re: ia64 gas default mode Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2005-01/txt/msg00287.txt.bz2 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 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