search for: outputelfwriter

...collect extra symbols during execution and then check if some undefines left (as I originally planned). This sounds reasonable as in any case we must have all undefines resolved in order to continue the linking process. 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? We may then expose a simple interface to the descendants of the writers to give chance to handle undefines. Also, do we need this special symbol handling for any cases other than static linki...

I've been adding ELF/AArch64 support to lld based off the existing x86_64 code that is already there in lld. I've been able to compile and link a simple "Hello World"-type program. However, I'm getting what appears to be a misplacement/name change of the _start atom. When I do the link, the _start section gets named __tls_get_addr. The code inside this section appears to be

On Thu, Feb 19, 2015 at 10:40 PM, Denis Protivensky <dprotivensky at accesssoftek.com> wrote: > Shankar, > > Okay, I guessed the correct interface. > But what about the moment at which the function is called? > 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. > > -