From: Roland McGrath <roland@hack.frob.com>
To: Chris Metcalf <cmetcalf@tilera.com>
Cc: <libc-alpha@sourceware.org>, <libc-ports@sourceware.org>
Subject: Re: [PATCH] tile: support very large shared objects
Date: Sat, 03 Nov 2012 04:47:00 -0000 [thread overview]
Message-ID: <20121103044725.73A6A2C0FA@topped-with-meat.com> (raw)
In-Reply-To: Chris Metcalf's message of Friday, 2 November 2012 22:21:45 -0400 <201211030342.qA33glX8011417@farm-0002.internal.tilera.com>
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.
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.
One is to create it in configure. I think you can probably just put in
a sysdeps/.../configure.in:
AC_CONFIG_COMMANDS([config-tile.make],
[echo "config-cflags-mcmodel-large = $libc_cv_cc_mcmodel_large" > config.tile.make],
[libc_cv_cc_mcmodel_large=$libc_cv_cc_mcmodel_large])
and have it actually do the right thing. But I haven't played with using
AC_CONFIG_COMMANDS this way to be sure it really works. (Which macros
really work usefully in a fragment is hard to predict.)
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.
If you are creating it with configure, then I think it can be just:
$(common-objpfx)config-tile.make: $(common-objpfx)config.make ;
to take advantage of the config.make target in Makeconfig for correct
rebuilding after configure has been run again or changed.
If you don't do it in configure, then you just do it right there in your
target rule for config-tile.make. I'd still make it depend on config.make,
but give it nonempty commands that actually create the file by running the
compiler test:
$(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" > $@
or whatever it is. In this case, you might want to make it a more specific
name since it's really an entirely local thing in sysdeps/tile/Makefile and
you might as well just have one file per test, so just make it
config-mcmodel-large.mk or something.
I generally think it's nice to do less in configure when we can do it in
make reasonably cheaply. But I don't have a strong preference for which
way you do it, just that it be done cleanly and entirely by changing only
sysdeps configure and/or Makefile files.
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. And elf-init is not all of csu/, there's also gmon-start and
so forth. Not to mention libc.a--do you not want fully-static linking to
work with -mcmodel=large? 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
The tile assembly bits are of course up to you and I don't presume to make
any sense of them.
Thanks,
Roland
next prev parent reply other threads:[~2012-11-03 4:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-03 3:42 Chris Metcalf
2012-11-03 4:47 ` Roland McGrath [this message]
2012-11-03 13:28 ` Chris Metcalf
2012-11-05 21:31 ` Chris Metcalf
2012-11-07 18:12 ` Roland McGrath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121103044725.73A6A2C0FA@topped-with-meat.com \
--to=roland@hack.frob.com \
--cc=cmetcalf@tilera.com \
--cc=libc-alpha@sourceware.org \
--cc=libc-ports@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).