<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Sep 8, 2014, at 4:34 PM, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>> wrote:</div><br class="Apple-interchange-newline"><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>
I thought translationUnitSource was pointing to the line table
information for the Atom ? <br></div></div></blockquote><div>That is where the reader would get the information from.</div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><div class="moz-cite-prefix">
<br>
The gnu linker produces an error message by looking at the line
table information when there is a undefined symbol.<br></div></div></blockquote><div>That could be another use for translationUnitSource().</div><div><br></div><div>-Nick</div><div><br></div><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><div class="moz-cite-prefix"><br>
On 9/8/2014 4:47 PM, Rui Ueyama wrote:<br>
</div>
<blockquote cite="mid:CAJENXgujukmfaUkxDo1bn1dyXTvFETTUwvdm0cYuVBASRNzPbA@mail.gmail.com" type="cite">
<pre wrap="">On Mon, Sep 8, 2014 at 2:28 PM, Nick Kledzik <a class="moz-txt-link-rfc2396E" href="mailto:kledzik@apple.com"><kledzik@apple.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Sep 8, 2014, at 2:19 PM, Rui Ueyama <a class="moz-txt-link-rfc2396E" href="mailto:ruiu@google.com"><ruiu@google.com></a> wrote:
On Mon, Sep 8, 2014 at 2:00 PM, Nick Kledzik <a class="moz-txt-link-rfc2396E" href="mailto:kledzik@apple.com"><kledzik@apple.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Sep 6, 2014, at 6:23 PM, Rui Ueyama <a class="moz-txt-link-rfc2396E" href="mailto:ruiu@google.com"><ruiu@google.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">- /// \brief Returns the path of the source file used to create the
</pre>
</blockquote>
<pre wrap="">object
</pre>
<blockquote type="cite">
<pre wrap="">- /// file which this (File) object represents. This information is
</pre>
</blockquote>
<pre wrap="">usually
</pre>
<blockquote type="cite">
<pre wrap="">- /// parsed out of the DWARF debug information. If the source file
</pre>
</blockquote>
<pre wrap="">cannot
</pre>
<blockquote type="cite">
<pre wrap="">- /// be ascertained, this method returns the empty string.
- virtual StringRef translationUnitSource() const;
-
</pre>
</blockquote>
<pre wrap="">I’ll be needing this or some equivalent in a few weeks when I add “debug
mapâ€[1] support to mach-o part of lld.
But translationUnitSource() is just one of a handful of File-level
attributes that mach-o will need. And these attributes are probably not
useful on other platforms, so we should work out a design for this. Some
of the other File level attributes mach-o needs are: min-OS, platform (e.g.
iOS simulator vs MacOSX), Objective-C flavor, Swift language version, auto
linking hints, debug map from -r merging, etc. Some possible designs:
1) Add a method to lld::File for each attribute (e.g. t
translationUnitSource()) and have them do nothing for ELF and COFF.
2) Add a generic dictionary method to lld::File. The dictionary might be
empty for ELF and COFF readers, but the mach-o reader would populate the
dictionary with some key/value encoding for each attribute it needs (e.g.
“minOS†—> “10.9â€).
3) Push this through the atom model by having a new
DefinedAtom::ContentType (e.g. typeMachOMeta) and having the mach-o reader
produce a new typeMachOMeta atom with the atom name being the “key†and the
atom’s content bytes being its “valueâ€. You can think of this like the
.comment section in ELF being transformed into an Atom. In mach-o most of
the extra attribute information is encoded in load commands in the file
header - not in sections, so there is no natural mapping to atoms.
</pre>
</blockquote>
<pre wrap="">I think I strongly prefer 1 over 2 or 3 as it seems simpler and more
straightforward than the others. It would be the easiest to implement for
you, and it wouldn't also hurt the others. No. 2 basically does the same
thing as No. 1 but in a rather complicated manner. No 3 is a possibility
but it really sounds like a hack.
I prefer No. 1 too. But we’ve tried to keep platform specific attributes
out of DefinedAtom. So, I wanted to make sure we were not keeping that
strictness for File too.
</pre>
</blockquote>
<pre wrap="">I want to keep the code shared by all architectures simple and clean, but
it doesn't always mean that we can only put the least common denominator
there. For example, if we are going to support an architecture on which the
linker's functionality is really limited, should we move the existing
shared code to each port, so that we don't have now-architecture-dependent
code in Core? Probably not. The functions you want to add falls in that
category. We should choose No. 1 for the sake of simplicity (= our
productivity).
-Nick
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">[1] Debug map:
On darwin, the linker does not copy dwarf debug info from .o files into
the final executable. Instead the linker generates a “debug map†in the
final executable. This is essentially a table that maps each function to
its .o file and source file. When you start debugging a program you just
built, the debugger sees no dwarf - just the debug map. If you set a break
in file “foo.c; line 100â€, the debugger will consult the debug map and see
which .o file(s) came from “foo.câ€. It will then open those .o files and
parse their dwarf debug info. It can then combine that dwarf info with the
debug map info to figure out what address in memory to set the break point.
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<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>
</div>
</blockquote></div><br></body></html>