Re: [PATCH] tile: support very large shared objects

[Chris Metcalf <cmetcalf@tilera.com>]

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