Home Original page

Concurrent linking plan for gold

Tom Tromey tromey@redhat.com
Sat Feb 7 20:35:00 GMT 2009 
>>>>> "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
More information about the Binutils mailing list