From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18421 invoked by alias); 3 Sep 2002 07:16:47 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 18398 invoked from network); 3 Sep 2002 07:16:46 -0000 Received: from unknown (HELO mx2.redhat.com) (205.180.83.106) by sources.redhat.com with SMTP; 3 Sep 2002 07:16:46 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id g8370ks00949; Tue, 3 Sep 2002 03:00:46 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g837Gfu21179; Tue, 3 Sep 2002 03:16:41 -0400 Received: from dot.sfbay.redhat.com (dot.sfbay.redhat.com [172.16.24.7]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g837Gfl03824; Tue, 3 Sep 2002 00:16:41 -0700 Received: (from rth@localhost) by dot.sfbay.redhat.com (8.11.6/8.11.6) id g837Gh408733; Tue, 3 Sep 2002 00:16:43 -0700 X-Authentication-Warning: dot.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Tue, 03 Sep 2002 00:16:00 -0000 From: Richard Henderson To: David Edelsohn Cc: Jeff Sturm , Alan Modra , Franz Sirl , Geoff Keating , gcc-patches@gcc.gnu.org Subject: Re: [RFC] PowerPC select_section / unique_section Message-ID: <20020903071643.GA8716@redhat.com> Mail-Followup-To: Richard Henderson , David Edelsohn , Jeff Sturm , Alan Modra , Franz Sirl , Geoff Keating , gcc-patches@gcc.gnu.org References: <200209030319.XAA22988@makai.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200209030319.XAA22988@makai.watson.ibm.com> User-Agent: Mutt/1.4i X-SW-Source: 2002-09/txt/msg00087.txt.bz2 On Mon, Sep 02, 2002 at 11:19:11PM -0400, David Edelsohn wrote: > Jeff> Some targets. Unless I'm very mistaken, all code is PIC on alpha, > Jeff> so that -fPIC has little effect apart from binds_local_p. Well, it also changes what sections data with relocations are placed in. But I think you underestimate what effect binds_local_p has -- variables that are known to be local are addressed with gp-relative relocations instead of through the got, calls within the same UOT use bsr, etc. > Jeff> Irrespective of PPC, wouldn't it be a desirable to have uniformity > Jeff> across GNU/Linux targets over this issue? Yes. But aside from PPC, I think we largely have that already. > Which seems like a good argument for default_binds_local_p and > others using a "pic" function parameter instead of grabbing the global > flag_pic. This would allow -fpic/-fPIC to affect targetm.binds_local_p > while not affecting the other functions. I don't see how that follows. In fact, I think that would simply be confusing to the many places that want to call binds_local_p. I would be willing to extract the bulk of default_binds_local_p into a default_binds_local_p_1 that did have a "shlib" parameter, and similar for select_section, but I don't want the choice of what value of flag_pic to pass to binds_local_p to reside at all of the call sites. r~