From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29994 invoked by alias); 3 Nov 2012 13:28:58 -0000 Received: (qmail 29981 invoked by uid 22791); 3 Nov 2012 13:28:57 -0000 X-SWARE-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from usmamail.tilera.com (HELO USMAMAIL.TILERA.COM) (12.216.194.151) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 03 Nov 2012 13:28:51 +0000 Received: from [192.168.1.104] (24.34.76.130) by USMAExch2.tad.internal.tilera.com (10.3.0.33) with Microsoft SMTP Server id 14.0.694.0; Sat, 3 Nov 2012 09:28:50 -0400 Message-ID: <50951C10.2050704@tilera.com> Date: Sat, 03 Nov 2012 13:28:00 -0000 From: Chris Metcalf User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Roland McGrath CC: , Subject: Re: [PATCH] tile: support very large shared objects References: <201211030342.qA33glX8011417@farm-0002.internal.tilera.com> <20121103044725.73A6A2C0FA@topped-with-meat.com> In-Reply-To: <20121103044725.73A6A2C0FA@topped-with-meat.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2012-11/txt/msg00011.txt.bz2 On 11/3/2012 12:47 AM, Roland McGrath wrote: > The elf.h changes are OK provided binutils trunk already has all those > exact names and numbers for those reloc codes. That's always good as > an isolated commit. OK, pushed. > I think we can avoid the changes to the generic configure/config.make for > something only one port uses in a couple of ways. > > In sysdeps/tile/Makefile do "include $(common-objpfx)config-tile.make". > That file will contain 'config-cflags-mcmodel = ...' or whatever you need. > Now, you have a couple of ways to go about creating that file. > > [...] > The other way is to create on the fly at build time. Either way you want > to add a $(common-objpfx)config-tile.make target in sysdeps/tile/Makefile. I took this approach. > $(common-objpfx)config-tile.make: $(common-objpfx)config.make > mcmodel=no; \ > $(CC) -S -o /dev/null -xc /dev/null -mcmodel=large || mcmodel=yes; \ > echo "config-cflags-mcmodel = $mcmodel" > $@ I used cflags-mcmodel-large as the variable name, and cflags-mcmodel-large.mk as the fragment filename. > csu/ is not enough. You also need to use the flag for all of *_nonshared.a > (.oS files). That too is code that's always statically linked into > applications. I did think about this. My conclusion was that since *_nonshared.a is linked last, it will always be at the end of the generated object, so jumps and calls will always be able to "reach" other things linked in from *_nonshared.a as well as the PLT, which immediately follows the text section. Thus, no need for large model. In practice this does appear to be the case. (And this large model code is noticeably slower than regular mode, and we've verified that it works at the customer with the actual large object this way, for what that's worth.) > And elf-init is not all of csu/, there's also gmon-start and > so forth. Ah, I didn't think about gmon-start. That ends up linked into the object statically for profiling, now that I look at it. Is it true that the rest are linked statically into shared objects? I thought many of them were just there for purely static build support. > Not to mention libc.a--do you not want fully-static linking to > work with -mcmodel=large? I think the performance penalty is enough that the answer is "no" by default. (A one-instruction call or jump becomes a four-instruction "load a register and jump" sequence.) If some customer needs a ginormous static binary, it's actually reasonable to just say "build a libc.a yourself and link against it". We just want to make sure the shared-object infrastructure "just works" for the case of large objects (as you suggest further down in your email). > So I think you want to do: > > CFLAGS-.o += -mcmodel=large > > (This will cover .oS files too, which is what you're after most.) If it's > too costly to do this for all of libc.a and you think people only want > static linking without the possibility of using -mcmodel=large or dynamic > linking with the possibility, then you can instead do: > > ifeq ($(subdir),csu) > CFLAGS-.o += -mcmodel=large > else > CFLAGS-.oS += -mcmodel=large > endif Thanks for your feedback. I'll post a modified patch for review shortly. -- Chris Metcalf, Tilera Corp. http://www.tilera.com