<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">My email client spoilt the whole email,
      will create a pdf and send it.<br>
      <br>
      On 9/20/2013 7:00 PM, Shankar Easwaran wrote:<br>
    </div>
    <blockquote cite="mid:523CE195.601@codeaurora.org" type="cite">Hi
      Nick,
      <br>
      <br>
      On 9/20/2013 5:59 PM, Nick Kledzik wrote:
      <br>
      <blockquote type="cite">On Sep 20, 2013, at 3:42 PM, Shankar
        Easwaran <a class="moz-txt-link-rfc2396E" href="mailto:shankare@codeaurora.org"><shankare@codeaurora.org></a> wrote:
        <br>
        <blockquote type="cite">nextFile could pass the current resolver
          state at the time when its called, the linkingcontext can
          return the next file to be processed as below :-
          <br>
          <br>
          nextFile(currentResolverState) :-
          <br>
          <br>
          a) Returns the next file if the current node is not a group
          node
          <br>
          b) Returns the next file in the group node, if the current
          node is a group node and the resolver state states undefined
          /weak / shared library atoms were added.
          <br>
          c) Returns the start file in the group node, if the resolver
          state states undefined/weak/shared library atoms were added
          <br>
          d) If the state is unchanged, no symbols were added exit the
          group and move to the next node.
          <br>
        </blockquote>
        What causes the Resolver state to change?   I understand the
        state of “there are undefines remaining”, but the “something was
        added” is a transient state.  Each last file, changes it.
        <br>
      </blockquote>
      Sorry for the long mail. This should explain things better.
      <br>
      <br>
      Here is a example with a state diagram on how the above proposal
      works. The main idea is to keep a running state of the resolver
      and the capturing the resolver state of each input file in the
      group by the linkingcontext.
      <br>
      <br>
      lld -flavor gnu main.o thread.o --start-group libc.a libpthread.a
      --end-group function.o
      <br>
      <br>
      main.o has atoms
      <br>
      ------------------------
      <br>
      main (defined)
      <br>
      printf(undefined)
      <br>
      fn(undefined)
      <br>
      <br>
      thread.o has atoms
      <br>
      -----------------------------
      <br>
      pthread_create (undefined)
      <br>
      <br>
      libc.a(printf.o) has atoms
      <br>
      ------------------------------------
      <br>
      printf(defined)
      <br>
      <br>
      libc.a(exit.o) has atoms
      <br>
      ----------------------------------
      <br>
      exit(defined)
      <br>
      <br>
      libpthread.a has atoms
      <br>
      ---------------------------------
      <br>
      pthread_create(defined)
      <br>
      exit(undefined)
      <br>
      <br>
      function.o has atoms
      <br>
      -------------------------------
      <br>
      fn(defined)
      <br>
      <br>
      <br>
      State diagram with time information
      <br>
      <br>
      Resolver resolverState                                         
      Context(nextFile)
      <br>
      -------------- ------------------ ----------------
      <br>
      resolverState = initialState
      <br>
      nextFile(resolverState) initialState
      ELFContextState=processingFileNode, return a.o
      <br>
      resolverState = nochange
      <br>
      process(a.o)
      <br>
      state = definedatoms/undefinedatoms (reason: main/printf)
      <br>
      nextFile(resolverState) definedAtoms/undefinedAtoms
      ELFContextState=processingFileNode, return b.o
      <br>
      resolverState = nochange
      <br>
      process(b.o)
      <br>
      state = undefinedatoms(reason: pthread_create)
      <br>
      nextFile(resolverState) undefinedAtoms
      ELFContextState=processingGroupNode, return libc.a
      <br>
      resolverState=nochange
      <br>
      process(libc.a)
      <br>
      process(printf.o)
      <br>
      state = definedatom (reason: printf)
      <br>
      nextFile(resolverState) definedAtoms
      ELFContextState=processingGroupNode, state[libc.a]=definedAtoms,
      return libpthread.a
      <br>
      resolverState=nochange
      <br>
      process(libpthread.a)
      <br>
      process(pthread.o)
      <br>
      state = definedatom/undefinedatoms (reason: pthread_create/exit)
      <br>
      nextFile(resolverState) definedAtoms/undefinedatoms
      ELFContextState=processingGroupNode,
      state[libpthread.a]=definedAtoms|undefinedAtoms, return libc.a
      <br>
      (returns the first file in the group)
      <br>
      <br>
      *LinkingContext would exit the GroupNode only if the state of each
      file in the group is unchanged, or has only definedAtoms.*
      <br>
      ///LinkingContext here, finds that libc.a has definedAtoms,
      whereas libpthread.a has undefinedAtoms, so traverses the group
      back./*
      <br>
      <br>
      *resolverState=nochange
      <br>
      process(libc.a)
      <br>
      process(exit.o)
      <br>
      state = definedatom (reason: exit)
      <br>
      nextfile(resolverState) definedAtoms
      ELFContextState=processingGroupNode, state[libc.a] = definedAtoms,
      return libpthread.a
      <br>
      resolverState=nochange
      <br>
      process(libc.a)
      <br>
      state = nochange
      <br>
      nextfile(resolverState) nochange
      ELFContextState=processingGroupNode, state[libpthread.a] =
      nochange,
      <br>
      <br>
      /                                          LinkingContext //finds
      that libc.a state has "definedAtoms", and libpthread.a has
      "nochange", so exits the group./*
      <br>
      <br>
      *resolverState=nochange
      <br>
      process(function.o)
      <br>
      state  = definedatom (reason: fn)
      <br>
      <br>
      Exit.
      <br>
      <br>
      Thanks
      <br>
      <br>
      Shankar Easwaran
      <br>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation</pre>
  </body>
</html>