This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Concurrent linking plan for gold
- From: Tom Tromey <tromey at redhat dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: binutils at sourceware dot org
- Date: Sat, 07 Feb 2009 13:35:18 -0700
- Subject: Re: Concurrent linking plan for gold
- References: <m34p0nlxm6.fsf@google.com>
- Reply-to: tromey at redhat dot com
>>>>> "Ian" == Ian Lance Taylor <iant@google.com> writes:
Ian> Here is a plan for implementing concurrent linking for gold.
Sorry for waiting so long to respond to this...
Ian> foo-concurrent-link: foo.c bar.c
Ian> $(CC) -o foo -Wl,--concurrent-inotify -Wl,--start-concurrent foo.o bar.o -Wl,--end-concurrent > foo-concurrent-link
Ian> foo-concurrent-link: foo.c bar.c
Ian> mkfifo foo-pipe
Ian> $(CC) -o foo -Wl,--concurrent-pipe,foo-pipe -Wl,--start-concurrent foo.o bar.o -Wl,--end-concurrent > foo-concurrent-link
It seems to me that a build tool like Automake or Quagmire would need
a way to decide which of these cases to use. It would be nice if gold
had an option to print this.
Why make the Makefile create the FIFO in the second case? Why not
have gold do it?
I like Daniel's idea of a 'gold-notify' program, to avoid touching an
unmodified object file in the inotify case. However, if you do this,
it seems to me that there isn't a very big advantage to having an
inotify path at all. If that is true, then a simpler interface would
be nicer for build tools -- just have a single way to invoke gold, and
always use gold-notify.
Alternatively, I suppose in the inotify case you could dispense with
gold-notify, and just do all the remaining processing at the
--concurrent-wait step. I guess this would lose a bit of concurrency
in the average case, though, where make schedules some unmodified
objects earlier than the compilations.
Tom