<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Nick,<br>
<br>
Thanks for getting back on this and clearing things up.<br>
<br>
Having a group atom with typeSignature is going to really
complicate things, that there are two symbol names that need to be
dealt with. The additional problem is if there is a relocation
relative to the signature atom, it would be hard to figure out
what atom to really bind the relocations to also.<br>
<br>
I think the best way to accomodate solving resolution of section
groups is not using a group atom with typeSignature, and using the
group atom as the signature atom.<br>
<br>
I want to understand a little bit more here.<br>
<br>
As you mentioned on ELF, the group section identified by the
signature atom has members that are essentially sections. Are you
saying that the signature atom has kindGroupMember references to
the <b>section atoms ? <br>
<br>
</b>The atoms that are part of the ELF section know that they are
part of the group and they would have a <b>kindSignature </b>reference
to the <b>signature atom.<br>
<br>
</b>I am depicting what I mentioned with an example :<br>
<br>
defined-atoms:<br>
- name: mysignature<br>
scope: global<br>
type: typeCode<br>
references:<br>
<b> - kind: group-member</b><br>
offset: 0<br>
<b> target: L001 /* section */ </b><br>
<b> - kind: group-member</b><br>
offset: 0<br>
<b> target: L002 </b><br>
# <b>section reference is L001</b><br>
<b> - ref-name: L001 </b><br>
scope: global<br>
references:<br>
- kind: layout-after<br>
offset: 0<br>
target: foo<br>
<b> - kind: group-signature</b><br>
offset: 0<br>
<b> target: mysignature</b><br>
- name: foo<br>
scope: global<br>
references:<br>
<b> - kind: group-signature</b><br>
offset: 0<br>
<b> target: mysignature</b><br>
<b>#section reference L002</b><br>
<b>- ref-name: L002 </b><br>
scope: global<br>
references:<br>
- kind: layout-after<br>
offset: 0<br>
target: bar<br>
<b> - kind: group-signature</b><br>
offset: 0<br>
<b> target: mysignature</b><br>
- name: bar<br>
scope: global<br>
references:<br>
<b> - kind: group-signature</b><br>
offset: 0<br>
<b> target: mysignature</b><br>
<br>
The reason I just listed the group-members to just sections were
just to make sure that we are able to build the group section when
we need to start supporting 'partial linking'. <br>
<br>
I have more questions related to symbol resolution after we
finalize the design for having the group-signature and
group-member references.<br>
<br>
Thanks again.<br>
<br>
Shankar Easwaran<br>
<br>
On 2/26/2014 9:07 PM, Nick Kledzik wrote:<br>
</div>
<blockquote
cite="mid:4CB786DE-0054-4C80-AC64-8D7882EFE7EA@apple.com"
type="cite">
<pre wrap="">Shankar,
Getting back to this. The ELF model is that a relocatable file can contain sections of type SHT_GROUP and the content of those sections are indices of other sections. Those other sections must all remain or all be removed. The groups have a name called the signature. A variant of this is when the SHT_GROUP’s section flags has GRP_COMDAT set. The group is now like a weak-definition in that there may be duplicates which a silently discarded.
Your idea is to introduce a new DefinedAtom (with a new ContentType) which represents the group. It is a atom with no content, but has references to all the members of the group. And the members each have a reference back to the group atom.
The problematic areas I see are:
1) The group can have a name. Currently all named atoms get added to the output file’s symbol table. Either we need a new attribute on (Defined)Atom that specifies whether or not the name gets added to the symbol table (ld64 has this), or the writer will need to check the contentType() and special case group atoms.
2) In the case of group comdat, the group signature will be the the name of one of the atoms. Which means you’d have two atoms with the same name competing to be in the symbol table. Or the symbol table special cases groups, or we need an Atom attribute to ignore the name.
3) If groups (non-comdat) are determined to replace one another by name, then they need a name that goes into the symbol table. But that name may need to be prefixed or something to keep if from colliding with real symbol names - or maybe that is considered a bug in the object file??
4) This common case (with template instantiation) of group comdat is modeled in ld64 by having the same named atom in the group become the signature atom. So there is no group atom. Each member just has a reference to the signature atom. I don’t know if this optimization would improve ELF groups in lld or make them more complicated.
5) We need a way to enforce the references to atoms that are in a group are either from within the group, are to the signature atom, or are indirected in a way that if the group is swapped out that they are properly replaced.
6) We need to defined if groups can be nested (a tree of groups) and if not, enforce that.
7) If we get this worked out, it may be able to replace the layoutBefore and layoutAfter stuff. Just put everything in a section into the same implicit group…
-Nick
On Feb 6, 2014, at 11:27 AM, Shankar Kalpathi Easwaran <a class="moz-txt-link-rfc2396E" href="mailto:shankarke@gmail.com"><shankarke@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> ELF does use the COMDAT(SHF_COMDAT) type to discard identical sections which are part of group. Section groups on ELF are modeled by using .group sections. The identical sections are grouped by using a signature symbol that is pointed to by the .group section in the input file.
The reason I would like to have the typeSignature property associated with the group is
- On ELF, the .group section contains section indices that are part of a group. I think its only ok to say that kindGroupSignature be associated only with the sections that are part of the group. The individual sections that are part of the COMDAT group are converted to atoms and I think those atoms **should not** have //kindGroupSignature //references.
- The signature symbol needs to be just discarded in the final executable, there is no need to keep them around in the executable/dynamic library
- The signature symbol can be overridden by a defined symbol or an undefined symbol.
- At the time of parsing each section by the ELF reader, the ELF reader need not special case that the section was part of which group ?
Thoughts/Opinions ?
<a class="moz-txt-link-freetext" href="http://llvm-reviews.chandlerc.com/D2710">http://llvm-reviews.chandlerc.com/D2710</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
llvm-commits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</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>