From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11406 invoked by alias); 29 Jun 2004 23:49:06 -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 11359 invoked from network); 29 Jun 2004 23:49:06 -0000 Received: from unknown (HELO bluesmobile.specifixinc.com) (64.62.200.227) by sourceware.org with SMTP; 29 Jun 2004 23:49:06 -0000 Received: from localhost.localdomain (bluesmobile.corp.specifixinc.com [10.0.0.1]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 12A7516623; Tue, 29 Jun 2004 16:49:05 -0700 (PDT) Subject: Re: PATCH: IA64: Don't relax branch in .init/.fini sections. From: Jim Wilson To: "H. J. Lu" Cc: binutils@sources.redhat.com In-Reply-To: <20040627055341.GA3067@lucon.org> References: <20040627004811.GA31373@lucon.org> <20040627055341.GA3067@lucon.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 29 Jun 2004 23:49:00 -0000 Message-Id: <1088552945.1194.49.camel@localhost> Mime-Version: 1.0 X-SW-Source: 2004-06/txt/msg00576.txt.bz2 On Sat, 2004-06-26 at 22:53, H. J. Lu wrote: > * elfxx-ia64.c (elfNN_ia64_relax_section): Don't relax branch > in .init/.fini sections. This looks OK to me. You suggest using brl. The gcc startup files deliberately use indirect branches to avoid this problem. We load the function address into a register, and then branch on the register. This also avoids use of brl which is a slow on an Itanium1. If we can ignore Itanium1, then we can simplify the gcc startup code a little bit. The error message doesn't give any hint about which instruction can't be relocated. Which means if you have lots of them you are screwed. This might be rare enough that we don't have to worry about it. You didn't give any info on how the problem was detected, so I can't tell if this matters. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com