<html>
<head>
</head>
<body bgcolor="#FFFFFF" text="#000000">
Joerg:<br>
<blockquote type="cite"><font size="2">> I propose to add the
ability to ignore undefined symbols during initial<br>
> resolution, and then postprocess only those undefines for
the second time<br>
> after the pass manager execution.<br>
<br>
Do you want to do that before or after dead code elimination?</font></blockquote>
I think dead code elimination should be performed after all possible
object code modifications done by lld. Therefore, it should be done
after undefines' postprocessing as well.<br>
<br>
Shankar:<br>
<blockquote type="cite"><font size="2">> I propose to add the
ability to ignore undefined symbols during initial<br>
> resolution, and then postprocess only those undefines for
the second 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 ?</font></blockquote>
With this option, I don't see:<br>
- how to postpone processing and reaction on undefines. If the
callback is called from within Resolver::resolve(), you should react
on it immediately, because otherwise the code will still fail in
Resolver::resolve().<br>
- how to know if a symbol is needed within the callback body. The
need of any symbol is determined in some other place. So I need to
keep a sort of indication (boolean flags, whatever) to know which
symbols are really needed.<br>
- the exact interface of notifyUndefinedSymbol callback. If it
receives `StringRef` name of the undefined symbol, what reaction
should be? Should it return new symbols to add back to the caller as
`const Atom*`?<br>
<br>
Thanks,<br>
Denis.<br>
</body>
</html>