<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2/27/2014 1:59 PM, Nick Kledzik
wrote:<br>
</div>
<blockquote
cite="mid:0213168A-3D73-43D4-BCA6-537E4011056A@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br>
<div>
<div>On Feb 27, 2014, at 11:33 AM, Shankar Easwaran <<a
moz-do-not-send="true" href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>>
wrote:</div>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">The group names dont collide
with regular symbol names, and the linker keeps the group
names in the same namespace too.<br>
</div>
</div>
</blockquote>
<div>But your example below shows the group name colliding with
the global variable name. So is the writer supposed to give
groups names that won’t collide with regular user symbol
names? If so, what about comdat?</div>
<br>
</div>
</blockquote>
I am not sure here, as it appears the symbol g1 should need to be
treated as though its living in 2 namespaces(one in the .group
section as the signature, and the .data section that contains g1
too)<br>
<br>
Bigcheese ?<br>
<br>
$ cat comdat1.s<br>
.global g1<br>
.section .foo,"axG",@progbits,g1,comdat<br>
.section .data, "aw",@progbits<br>
.global g1<br>
g1:<br>
.word 10<br>
<br>
Here g1, is the signature of the group and we have a global symbol
g1(data).<br>
<br>
When I dump the symbol table, I find only one symbol g1.<br>
<br>
$ objdump -Clx comdat1.o | grep g1<br>
0000000000000000 g <b>.data </b> 0000000000000000 <b>g1</b><br>
<br>
Thanks<br>
<br>
Shankar Easwaran<br>
<br>
<blockquote
cite="mid:0213168A-3D73-43D4-BCA6-537E4011056A@apple.com"
type="cite">
<div>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"> <br>
Below is an example :-<br>
<br>
cat > comdat1.s << \!<br>
.global g1<br>
.section .foo,"axG",@progbits,g1,comdat<br>
g1:<br>
.word 5<br>
!<br>
<br>
cat > comdat2.s << \!<br>
.global g1<br>
.section .foo,"axG",@progbits,g1,comdat<br>
g1:<br>
nop<br>
!<br>
<br>
cat > global-g1.c << \!<br>
int g1 = 1000;<br>
int fn() { return g1;}<br>
!<br>
<br>
clang -c comdat1.s comdat2.s global-g1.c<br>
ld comdat1.o comdat2.o global-g1.o --noinhibit-exec<br>
<br>
<b>global-g1.o:(.data+0x0): multiple definition of `g1'<br>
comdat1.o:(.foo[g1]+0x0): first defined here<br>
</b><br>
I get a multiple definition error, that g1 is multiply
defined.<br>
<br>
Thanks<br>
<br>
Shankar Easwaran<br>
<br>
<br>
On 2/27/2014 12:59 PM, Nick Kledzik wrote:<br>
</div>
<blockquote
cite="mid:A702CD29-D1F5-4464-B17C-8B4ED7862F04@apple.com"
type="cite">The lld model is atom-centric whereas ELF is
section-centric. In the example yaml below, you seem to
be keeping sections disguised as atoms. I think that
intermediate layer is not needed. For example:
<div><br>
</div>
</blockquote>
<br>
The only reason I thought of keeping the intermediate layer
is the linker has another mode to generate
relocatables/partial linking mode. The partial linking step
creates another .o from the set of .o's during the link.<br>
<br>
At that point of time, it would be needed to recognize what
are the actual group members(section indices) that needs to
kept in the .group, could we have another reference kind to
keep that info ?<br>
</div>
</blockquote>
<div>In that mode, it can find all atoms of typeGroup and make a
SHT_GROUP for each. For each group it looks at each child,
and if each child is in its own section, then just add those
section indexes to the parent group’s content. If a child is
in a section shared with atoms not in the group, then child
will need to be moved to its own section (whose index is added
to the parent content).</div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"> <br>
<br>
<blockquote
cite="mid:A702CD29-D1F5-4464-B17C-8B4ED7862F04@apple.com"
type="cite">
<div>ELF foo.o contains:</div>
<div><br>
</div>
<div> section 1: SHT_GROUP , name=“g1”, content=3,4</div>
<div> section 3: </div>
<div> symbol: name=“f1”, size=30</div>
<div> symbol: name=“f2”, size=16</div>
<div> section 4: </div>
<div> symbol: name=“d1”, size=4</div>
<div> section 5: </div>
<div> symbol: name=“f3”, size=30</div>
</blockquote>
<br>
In the above example, if I want to use partial linking, the
partial linking step preserves the group information as is,
as in :-<br>
<br>
ld -r foo.o -o partiallink.o<br>
<br>
The partial link.o would still have :-<br>
<br>
<div> section 1: SHT_GROUP , name=“g1”, content=3,4</div>
<div> section 3: </div>
<div> symbol: name=“f1”, size=30</div>
<div> symbol: name=“f2”, size=16</div>
<div> section 4: </div>
<div> symbol: name=“d1”, size=4</div>
<div> section 5: </div>
<div> symbol: name=“f3”, size=30</div>
<br>
Thanks<br>
<br>
Shankar Easwaran<br>
<br>
<blockquote
cite="mid:A702CD29-D1F5-4464-B17C-8B4ED7862F04@apple.com"
type="cite">
<div> </div>
<div>In the above (made up syntax), the file has three
functions and once global variable. f1, f2, and d1 are
in the the group named g1. The last function f3 is not
in any group.</div>
<div><br>
</div>
<div>I would see the parsed into the lld model as:</div>
<div><br>
</div>
<div><font size="1" face="Monaco">defined-atoms:<br>
- name: g1<br>
scope: global<br>
type: typeGroup<br>
references:<br>
- kind: group-child<br>
target: f1<br>
- kind: group-</font><span
style="font-family: Monaco; font-size: x-small;">child</span><font
size="1" face="Monaco"><br>
</font>
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><font size="1"
face="Monaco"> target: f2 <br>
</font></div>
</div>
</div>
<div>
<div><font size="1" face="Monaco"> -
kind: group-</font><span
style="font-family: Monaco; font-size: x-small;">child</span><font
size="1" face="Monaco"><br>
</font>
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><font size="1"
face="Monaco"> target: d1 <br>
</font></div>
<div><font size="1" face="Monaco"> -
name: f1<br>
scope: global<br>
type: typeCode<br>
</font></div>
</div>
</div>
</div>
<div><font size="1" face="Monaco"> references:<br>
- kind: group-parent<br>
target: g1<br>
</font></div>
<div>
<div>
<div text="#000000" bgcolor="#FFFFFF"><font size="1"
face="Monaco"> - name: f2<br>
scope: global<br>
type: typeCode<br>
</font></div>
</div>
<div><font size="1" face="Monaco"> references:<br>
- kind: group-</font><span
style="font-family: Monaco; font-size: x-small;">parent</span><font
size="1" face="Monaco"><br>
target: g1<br>
</font></div>
</div>
<div>
<div>
<div>
<div text="#000000" bgcolor="#FFFFFF"><font size="1"
face="Monaco"> - name: d1<br>
scope: global<br>
type: typeData<br>
</font></div>
</div>
<div><font size="1" face="Monaco"> references:<br>
- kind: group-</font><span
style="font-family: Monaco; font-size: x-small;">parent</span><font
size="1" face="Monaco"><br>
target: g1<br>
</font></div>
</div>
</div>
<div>
<div>
<div>
<div text="#000000" bgcolor="#FFFFFF"><font size="1"
face="Monaco"> - name: f3<br>
scope: global<br>
type: typeCode</font></div>
</div>
<div><br>
</div>
</div>
</div>
<br>
<div>
<div>On Feb 26, 2014, at 8:38 PM, Shankar Easwaran <<a
moz-do-not-send="true"
href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>>
wrote:</div>
<blockquote type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>
<a moz-do-not-send="true" 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>
</div>
</blockquote>
</div>
<br>
</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>
</div>
</blockquote>
</div>
<br>
</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>