From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23644 invoked by alias); 29 Jan 2005 01:49:21 -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 23453 invoked from network); 29 Jan 2005 01:49:03 -0000 Received: from unknown (HELO bluesmobile.specifixinc.com) (64.220.152.98) by sourceware.org with SMTP; 29 Jan 2005 01:49:03 -0000 Received: from [127.0.0.1] (bluesmobile.corp.specifixinc.com [192.168.1.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 5A19316786; Fri, 28 Jan 2005 17:49:03 -0800 (PST) Subject: Re: [PATCH] ia64 unwind directive semantics From: James E Wilson To: Jan Beulich Cc: binutils@sources.redhat.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1106963343.24728.50.camel@aretha.corp.specifixinc.com> Mime-Version: 1.0 Date: Sat, 29 Jan 2005 01:49:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-01/txt/msg00502.txt.bz2 On Fri, 2005-01-28 at 01:42, Jan Beulich wrote: > Jim wilson wrote: > >Hopefully gcc emits unwind info that passes all of these tests. > So do I hope. But if not, they're at fault... I already noticed one. The gcc -pg support is broken, it both emits instructions without unwind info, and does a section switch. This will need to be fixed. It won't work anymore after this patch goes in. This is GCC PR 12455, and Steve Ellcey is looking at the problem because gcc -pg doesn't work right under HPUX. > Actually, if you use expr_build_dot at the point or .proc, things may > get entirely wrong if the primary entry point doesn't immediately > follow. Yes, either way, we need to make assumptions, and it isn't clear that either set of assumptions is worse than the other. I'm willing to go along with your patch, but if I find a problem I will switch back to the old way. In theory, everyone should be emitting the function label immediately after the .proc, and giving the function name as the first argument to the .proc, in which case it doesn't matter which way we do this. Either way we get the same answer, so in theory this change should be harmless. This patch is OK. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com