<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">Hi Rui,<br>
<br>
Yes, I am fine with it. The derived classes of TargetInfo should
also match their names.<br>
<br>
ELFTargetInfo has multiple TargetInfo's that derive from it
(PPCTargetInfo, X86_64TargetInfo, HexagonTargetInfo).<br>
<br>
Thanks<br>
<br>
Shankar Easwaran<br>
<br>
On 7/23/2013 12:57 PM, Rui Ueyama wrote:<br>
</div>
<blockquote
cite="mid:CAJENXgt4+o-zRVGCN71+sm3TjFp7HCw4AwENMenF1ZJb_90H0Q@mail.gmail.com"
type="cite">
<pre wrap="">Michael and Shankar, any thoughts?
On Sun, Jul 21, 2013 at 5:49 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="">A couple of thoughts:
1) The name TargetInfo does not describe what this class is doing and does
not help resolve this. We should consider renaming it.
2) The TargetInfo object is the one "context" object passed around
throughout the linker. It would be a pain to pass around two objects (a
const and non-const object). *If* we wind up with two objects, then the
non-const one should hold a reference to the the const one, and just have
the non-const one passed everywhere.
3) I think the motivation for it being const is that with lld as a library
(say for JIT'ing code) you may want to set it up once and re-use it for
multiple links. This presupposes that constructing and setting one up is
expensive.
So, my feeling is that we keep one object, but renaming it something like
LinkingContext, and strive to have a way to make construction cheap. For
instance, have a MachOLinkingContext constructor that takes a few
parameters and quickly initializes an object in a way useful for most
library clients, as opposed to passing a command line list which must be
parsed to construct the object.
</pre>
</blockquote>
<pre wrap="">
+1. I'm in favor of renaming.
</pre>
<blockquote type="cite">
<pre wrap="">
-Nick
On Jul 21, 2013, at 5:25 PM, Rui Ueyama wrote:
Here is the background information about this topic, I'll write it down
for convenience.
*Issue*
Some types of object files may have directives to the linker which has
side effects. Specifically I know there are two cases:
- COFF object file
On Windows, the object file may contain linker options in .drectve
section, and the linker needs to handle them as if it were given via the
command line. This feature is used mainly for propagating required library
name from the compiler to the linker, so that you can omit /defaultlib
option (which is mostly equivalent to Unix -l option) when linking, but
it's a generic feature and not limited to that.
- Linker script
Many linker script directives, such as ENTRY or SEARCH_DIR, need to update
TargetInfo information.
TargetInfo is the object having all the information needed by the core
linker. It's constructed by the driver based on the command line (or in
some way if used as a library), and passed to the core linker. The core
linker links objects as instructed by a TargetInfo. The core linker treats
a TargetInfo as a const object, so that we can reuse a TargetInfo multiple
times.
The needs to update the TargetInfo conflicts with the constness.
I remember Nick suggested two pass solution. In the first pass, we read
all the object files given via the command line only to gather linker
directives to construct a TargetInfo. In the second pass, the TargetInfo is
passed to the core linker and is treated as a const object. This might work
for ELF, but wouldn't for COFF, because of the issue when linking the
archive file. We should not parse directives of all files in a library
file, but parse only the file needed for linking. That information is not
available until we actually try to link objects, so we can't split it into
two passes.
On Sun, Jul 21, 2013 at 4:55 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="">I think we've now got to the point where we should revisit the topic
about how to handle linker directives embedded in the input file for
further development of the lld linker. We had a discussion in May for
<a class="moz-txt-link-freetext" href="http://llvm-reviews.chandlerc.com/D833">http://llvm-reviews.chandlerc.com/D833</a>, but at that time we didn't reach
a conclusion.
It appears to me that there are two choices to handle it.
1. Treat TargetInfo as a mutable object
It's a simple solution, but we will lose reusability of TargetInfo.
2. Make TagetInfo clonable
Make a copy of a TagetInfo in the core linker and use it internally. It
probably needs large refactoring of TargetInfo because the class currently
has many non-copyable members.
I'm inclined to choice 1, for choice 2 seems to need too much work. What
do you guys think?
</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>
</body>
</html>