This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 2/2] gold: add a task in incremental build that can be used to check which inputs were modified
- From: Cary Coutant <ccoutant at google dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Mikolaj Zalewski <mikolajz at google dot com>, binutils at sourceware dot org
- Date: Mon, 23 Mar 2009 11:36:52 -0700
- Subject: Re: [PATCH 2/2] gold: add a task in incremental build that can be used to check which inputs were modified
- References: <7ebec9e70903171609h29b0dfe7wab760614e1e6d5bb@mail.gmail.com> <m3tz5noezy.fsf@google.com>
>> ? I don't know how plug-ins interacts with this - when do plugins add
>> input objects? Currently I print an error if they do it too late.
>
> I *think* that when a plugin adds an input file we have to assume it is
> modified. ?In any case this is certainly lower priority.
Plugins add their replacement files during the Plugin_hook task, which
runs after the last Read_symbols task, and before Gc_runner or
Middle_runner.
Treating a replacement file as modified sounds like the right thing.
If it was going to be unmodified, we probably wouldn't/shouldn't have
processed the file that got claimed by the plugin in the first place.
In any case, incremental linking with LTO is going to take some deep
thought.
-cary