Re: [PATCH] Make --start-lib/--end-lib block on previous add symbols tasks

[Neil Vachharajani <nvachhar at google dot com>]

On Thu, Aug 19, 2010 at 3:09 PM, Ian Lance Taylor <iant@google.com> wrote:
> Neil Vachharajani <nvachhar@google.com> writes:
>
>> This patch fixes a problem where when using --start-lib/--end-lib the
>> linker would report that certain symbols could not be found. ?The
>> problem was that the add symbols task for a group of object files
>> surrounded by --start-lib/--end-lib was not appropriately waiting for
>> previous add symbols tasks. ?This patch uses an Unblock_token to
>> properly serialize the execution.
>>
>> OK to apply? ?Tested on x86_64 Linux.
>>
>> ChangeLog:
>>
>> ? ? ? ? gold/
>> ? ? ? ? * readsyms.cc (Read_symbols::do_lib_group): Block
>> add_lib_group_symbols on this->this_blocker.
>
> This doesn't look optimal. ?The tasks here are:
>
> ?1) Read_symbols task, with this_blocker and next_blocker.
> ?2) Add_lib_group_symbols task.
> ?For each file between --start-lib/--end-lib:
> ? ?3) Read_symbols task.
>
> I think the dependencies are:
>
> ?A) Each 3) task must run before the 2) task starts.
>
> ?B) The 2) task must not start until the 1) this_blocker is unblocked.
>
> ?C) The 2) task must unblock the 1) next_blocker.
>
> The current code implements A and C, but not B. ?The way to implement B
> is to pass this_blocker_ to Add_lib_group_symbols, and have it check it
> in Add_lib_group_symbols::is_runnable.
>
> There is no need for an additional Unblock_token task here.

That was the way I originally implemented it :)  But talking to Cary
we couldn't find a precedent of having two blockers for one task.
I'll send a new patch where Add_lib_group_symbols takes two blockers
(the existing one and the additional one you describe) and send a new
patch.

>
> Ian
>



-- 
Neil Vachharajani
Google
650-214-1804