From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25482 invoked by alias); 28 Jan 2005 05:05:01 -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 25431 invoked from network); 28 Jan 2005 05:04:55 -0000 Received: from unknown (HELO bluesmobile.specifixinc.com) (64.220.152.98) by sourceware.org with SMTP; 28 Jan 2005 05:04:55 -0000 Received: from [127.0.0.1] (bluesmobile.corp.specifixinc.com [192.168.1.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 1D20F16798; Thu, 27 Jan 2005 21:04:55 -0800 (PST) Subject: Re: [PATCH] ia64 bundle alignment From: James E Wilson To: Jan Beulich Cc: binutils@sources.redhat.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1106888694.18514.260.camel@aretha.corp.specifixinc.com> Mime-Version: 1.0 Date: Fri, 28 Jan 2005 05:05:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-01/txt/msg00471.txt.bz2 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