<html>
<head>
</head>
<body bgcolor="#FFFFFF" text="#000000">
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 me as I cannot determine the need of specific symbols
at that time.<br>
<br>
- Denis.<br>
<br>
<div class="moz-cite-prefix">On 02/19/2015 08:15 PM, Shankar
Easwaran wrote:<br>
</div>
<blockquote cite="mid:54E61A1E.2030005@codeaurora.org" 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 -->
<p><font size="2">+ 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 the Linux Foundation<br>
<br>
</font>
</p>
</blockquote>
<br>
</body>
</html>