This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] Make --start-lib/--end-lib block on previous add symbols tasks
- From: Ian Lance Taylor <iant at google dot com>
- To: Neil Vachharajani <nvachhar at google dot com>
- Cc: binutils at sourceware dot org
- Date: Thu, 19 Aug 2010 15:09:52 -0700
- Subject: Re: [PATCH] Make --start-lib/--end-lib block on previous add symbols tasks
- References: <AANLkTinVvgYHO+YEALV9WnUn-S9WBeo7LK0Qj3xYi85p@mail.gmail.com>
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.
Ian