Home Original page

Concurrent linking plan for gold

Ian Lance Taylor iant@google.com
Mon Dec 29 23:43:00 GMT 2008 
Daniel Jacobowitz <drow@false.org> writes:

> On Sun, Dec 28, 2008 at 02:54:09PM -0800, Ian Lance Taylor wrote:
>> Interface
>
> I like the interface generally.  One thing I disliked; having to
> touch files to inform the incremental linker that they're unchanged.
> How about having a tool "gold-notify" instead, which could use the
> open-writable/close pair?  I think that won't affect modification
> time.  Or if it does, gold-notify could use the pipe instead
> (opening the pipe even while using inotify shouldn't be a problem).

Good idea.  Thanks.


> I spent a little while thinking about the no-files-changed case.
> Because you have a dependency from object files to starting the
> incremental linker, make will always consider the destination program
> changed.

I don't *think* that is correct, because I doubled the dependencies.
The "start link" target also depends on the source files:

foo-concurrent-link: foo.c bar.c
foo.o: foo-concurrent-link foo.c
foo: foo.o bar.o

So if none of the source files have changed, foo-concurrent-link will
not be out of date.

But I have not actually tried this.


>> The more general case, in which the linker can process the files in
>> any order, is more complicated.  Here is a sketch of how it might
>> work.  Naturally these operations are all conditional on doing a
>> concurrent link.  This more general approach will not work when using
>> a linker script.
>
> This approach also causes each build to produce a different output
> file.  That means concurrent linking with this approach is only
> suitable during development, not for deployment.  Our workflow here
> does mostly deployable builds, so I wonder if there's any middle
> ground to take advantage of concurrency but still produce stable
> output.

Good point, and I'm not sure.

Ian
More information about the Binutils mailing list