This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]