<html>
<head>
</head>
<body bgcolor="#FFFFFF" text="#000000">
Okay, I understood that you're proposing to add all undefined
symbols during the resolution step, and not try to collect extra
symbols during execution and then check if some undefines left (as I
originally planned).<br>
This sounds reasonable as in any case we must have all undefines
resolved in order to continue the linking process.<br>
<br>
Concerning the implementation, why not to add this virtual archive
file to the OutputELFWriter (or even to ExecutableWriter) since we
already have a method to add specific files to the linking process?<br>
We may then expose a simple interface to the descendants of the
writers to give chance to handle undefines.<br>
<br>
Also, do we need this special symbol handling for any cases other
than static linking of the executable?<br>
<br>
- Denis.<br>
<br>
<div class="moz-cite-prefix">On 02/24/2015 06:44 AM, Nick Kledzik
wrote:<br>
</div>
<blockquote
cite="mid:4A912CE7-B434-4CA3-9350-523E93CBAE18@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="MS Exchange Server version
08.03.0377.000">
<title>Re: [LLVMdev] [lld] Undefined symbols postprocessing</title>
<!-- Converted from text/plain format -->
<br>
<p><font size="2">On Feb 23, 2015, at 2:52 PM, Michael Spencer
<a class="moz-txt-link-rfc2396E" href="mailto:bigcheesegs@gmail.com"><bigcheesegs@gmail.com></a> wrote:<br>
<br>
> On Thu, Feb 19, 2015 at 10:40 PM, Denis Protivensky<br>
> <a class="moz-txt-link-rfc2396E" href="mailto:dprotivensky@accesssoftek.com"><dprotivensky@accesssoftek.com></a> wrote:<br>
>> Shankar,<br>
>><br>
>> Okay, I guessed the correct interface.<br>
>> But what about the moment at which the function is
called?<br>
>> If it's called from Resolver::resolve(), it doesn't
make any difference to<br>
>> me as I cannot determine the need of specific symbols
at that time.<br>
>><br>
>> - Denis.<br>
><br>
> None of the symbols we are looking up require the full
resolver, and<br>
> they are all special linker symbols. I propose two
things.<br>
><br>
> 1. Provide a hook as per what Shankar suggested for the
resolver. User<br>
> references to linker defined symbols such as
_GLOBAL_OFFSET_TABLE_ get<br>
> created and possibly deadstripped here. The linking
context owns the<br>
> atom.<br>
> 2. The ELFLinkingContext gains <Atom<br>
> *getOrCreateLinkerDefinedAtom(StringRef);>. This can
be used in passes<br>
> to get the symbols. The hook in (1) would call this to
create the<br>
> atoms.<br>
><br>
> This gives a single place where linker defined atoms are
actually<br>
> created, and allows correct deadstripping and object file
references<br>
> without doing multiple resolver passes.<br>
As Rui showed, we already have this abstraction. The linking
context just adds a magic ArchiveFile. When queried for any
“linker defined symbol”, the magic ArchiveFile instantiates
the atoms needed.<br>
<br>
This is how mach-o handles linker defined symbols like
__dso_handle.<br>
<br>
-Nick<br>
<br>
<br>
><br>
>><br>
>><br>
>> On 02/19/2015 08:15 PM, Shankar Easwaran wrote:<br>
>><br>
>> + Nick<br>
>><br>
>> On 2/19/2015 9:00 AM, Shankar Easwaran wrote:<br>
>>> On 2/19/2015 3:58 AM, Denis Protivensky wrote:<br>
>>>> Joerg:<br>
>>>>> I propose to add the ability to ignore
undefined symbols during initial<br>
>>>>> resolution, and then postprocess only
those undefines for the second<br>
>>>>> time<br>
>>>>> after the pass manager execution.<br>
>>>> Do you want to do that before or after dead
code elimination?<br>
>>>> I think dead code elimination should be
performed after all possible<br>
>>>> object code modifications done by lld.
Therefore, it should be done<br>
>>>> after undefines' postprocessing as well.<br>
>>> Gnu does dead code elimination before undefines
are reported. So if a<br>
>>> function is not called and it has a undefined
reference its would not<br>
>>> be an undef.<br>
>>>><br>
>>>> Shankar:<br>
>>>>> I propose to add the ability to ignore
undefined symbols during initial<br>
>>>>> resolution, and then postprocess only
those undefines for the second<br>
>>>>> time<br>
>>>>> after the pass manager execution.<br>
>>>> I came across this same problem, and was
planning on adding a<br>
>>>> notifyUndefinedSymbol to the LinkingContext,
if the linker wants to add<br>
>>>> a defined symbol and coalesce it, it would be
possible.<br>
>>>><br>
>>>> Do you think this will work for your case too
?<br>
>>>> With this option, I don't see:<br>
>>>> - how to postpone processing and reaction on
undefines. If the<br>
>>>> callback is called from within
Resolver::resolve(), you should react<br>
>>>> on it immediately, because otherwise the code
will still fail in<br>
>>>> Resolver::resolve().<br>
>>>> - how to know if a symbol is needed within
the callback body. The<br>
>>>> need of any symbol is determined in some
other place. So I need to<br>
>>>> keep a sort of indication (boolean flags,
whatever) to know which<br>
>>>> symbols are really needed.<br>
>>>> - the exact interface of
notifyUndefinedSymbol callback. If it<br>
>>>> receives `StringRef` name of the undefined
symbol, what reaction<br>
>>>> should be? Should it return new symbols to
add back to the caller as<br>
>>>> `const Atom*`?<br>
>>> notifyUndefinedSymbol will allow the context to
coalesce the undefined<br>
>>> atom with a defined atom.<br>
>>><br>
>>> Atom *notifyUndefinedSymbol(StringRef name) could
be the interface.<br>
>>><br>
>>>> Thanks,<br>
>>>> Denis.<br>
>>>><br>
>>><br>
>>><br>
>><br>
>><br>
>> --<br>
>> Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by<br>
>> the Linux Foundation<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a
moz-do-not-send="true" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br>
>> <a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br>
> <a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
</font>
</p>
</blockquote>
<br>
</body>
</html>