[PATCH] [lld][core] sectionGroup support.

[Shankar Kalpathi Easwaran]

  For some reason, my comments and questions were not showing up on phabricator.

     [Core] add Section Group support

      This patch only provides an initial support to handle section groups in lld Core
      functionality.

      There is still a lot more stuff to do, that has to be fully handled. I have a
      few very critical questions related to the design.

      I tried various cases on ELF using a GNU linker to see what functionality it
      tries to achieve, lld need to achieve similar functionalities with ELF to handle
      section groups.

      The current code supports case (a), I would want to take early feedback before
      making it through the complete implementation though.

      Coded design
      ----------------
      Models a .group section on ELF. The .group section on ELF contains group members
      identified by the group's signature. The group signature is represented by
      a "typeSignature" atom. The members of the group are sections and those are
      represented as "Group members" and referenced through references internal to
      lld, called "group-member" references. The group-member section references have
      a list of atoms in a follow-on chain modeled using layout-after references and
      also contains a 'in-group' reference.

      I am taking an example of three files A, B, C here to document how section
      groups work on the GNU flavor.

      Case a
      ---------
      File A defines a group 'G', File B defines a group 'G'. The resolver when it
      looks at 'G' resolves all the references from B(G) to A(G).

      THIS IS THE ONLY CASE BEING HANDLED RIGHT NOW.

      Case b
      ---------
      File A defines a group 'G', File B defines a group G". The groups in File B
      differ in a particular data member (add/deleted).

      Nick mentions that a warning be provided for this. Yet to be done.

      Case c
      -----------
      File A defines a weak group 'G', where 'G' is a weak signature symbol.
      File B defines a group G. and G is a strong signature symbol.

      It appears that the GNU linker still picks up the group 'G' from A.

      Is this sort of behavior applicable on all platforms ?

      Case d
      -----------
      File A defines a weak group 'G', where 'G' is a undefined B   signature symbol.
      File defines a group G. and G is a strong signature symbol.

      It appears that the GNU linker still picks up the group 'G' from A, and produce
      a undefined reference.

      Is this sort of behavior applicable on all platforms ?

      Case e
      --------
      File A defines a group 'G', File B defines a group G, File C, ha the same
      symbol that the signature is based on as a undefined symbol.

      Gnu linker picks up the undefined symbol and rejects symbols from the group.

      Is this sort of behavior applicable on all platforms ?

      Case f
      --------
      File A defines a group 'G', File B defines a group G, File C, ha the same
      symbol that the signature is based on as a undefined symbol.

      Gnu linker picks up the undefined symbol and rejects symbols from the group.

      Is this sort of behavior applicable on all platforms ?

      What happens to the symbols in the group ? Are those thrown away.

      I am unable to conclude on a clean behavior here.

      What sort of behavior would you think would we want to handle ?

      Case g
      ---------
      How do discard eh_frame information from discarded groups ?

http://llvm-reviews.chandlerc.com/D2710