search for: resolveundefin

...he methods forEachInitalAtom() and searchLibraries() then we could get rid of InputFiles and have the Resolver uses InputGraph directly. Yes, this would be nice. I will try to write a proposal in the next few days. > What should the interface be that the Resolver uses for handling groups? bool resolveUndefines(std::vector<File> &files) ? This has to iterate over the files until it reaches a stable point (that no more resolution is possible). Thanks Shankar Easwaran > > -Nick > > On Sep 4, 2013, at 1:42 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > >&gt...

...e process is not dyld as exec on macOS only provides the mach header address to dyld (*1). They are used inside of dyld and I am now using them in “x86_64-xnu-musl”. It’s possible to resolve a mach-o segment offset or a mach-o section offset using these special ld64 linker synthesised symbols. See resolveUndefines: - https://opensource.apple.com/source/ld64/ld64-274.2/src/ld/Resolver.cpp.auto.html <https://opensource.apple.com/source/ld64/ld64-274.2/src/ld/Resolver.cpp.auto.html> There are 4 special symbol prefixes for the mach-o linker synthesised symbols: - segment$start$__SEGMENT - segment$end$...

...orEachInitalAtom() and searchLibraries() then we could get rid of InputFiles and have the Resolver uses InputGraph directly. > Yes, this would be nice. I will try to write a proposal in the next few days. >> What should the interface be that the Resolver uses for handling groups? > bool resolveUndefines(std::vector<File> &files) ? > > This has to iterate over the files until it reaches a stable point (that no more resolution is possible). It is a little more complicated. After initial .o files are processed, there are a bunch of undefines left. The resolver needs to start load...

...l there is one complete pass in which no new files were used. Also, is nextFile() going to be in InputGraph and directly accessed by the Resolver? Or is nextFile in LinkingContext (which forwards it to the InputGraph)? I assume the later. Currently, the Resolver has buildInitialAtomList() and resolveUndefines() which matches the way darwin links. I assume part of this change is to unify those two methods by just have one loop that uses nextFile(). Given that nextFile() is basically an iteration mechanism, perhaps we can make it conform to C++11 iterators. The one issue is the feedback of whether th...

...is not dyld as exec on macOS only provides the mach header address to dyld (*1). They are used inside of dyld and I am now using them in “x86_64-xnu-musl”. > > It’s possible to resolve a mach-o segment offset or a mach-o section offset using these special ld64 linker synthesised symbols. See resolveUndefines: > > - https://opensource.apple.com/source/ld64/ld64-274.2/src/ld/Resolver.cpp.auto.html <https://opensource.apple.com/source/ld64/ld64-274.2/src/ld/Resolver.cpp.auto.html> > > There are 4 special symbol prefixes for the mach-o linker synthesised symbols: > > - segment$...

...Atom() and searchLibraries() then we could get rid of InputFiles and have the Resolver uses InputGraph directly. >> Yes, this would be nice. I will try to write a proposal in the next few days. >>> What should the interface be that the Resolver uses for handling groups? >> bool resolveUndefines(std::vector<File> &files) ? >> >> This has to iterate over the files until it reaches a stable point (that no more resolution is possible). > It is a little more complicated. After initial .o files are processed, there are a bunch of undefines left. The resolver needs t...

...the mach header >> address to dyld (*1). They are used inside of dyld and I am now using them >> in “x86_64-xnu-musl”. >> >> It’s possible to resolve a mach-o segment offset or a mach-o section >> offset using these special ld64 linker synthesised symbols. See >> resolveUndefines: >> >> - https://opensource.apple.com/source/ld64/ld64-274.2/src/ >> ld/Resolver.cpp.auto.html >> >> There are 4 special symbol prefixes for the mach-o linker synthesised >> symbols: >> >> - segment$start$__SEGMENT >> - segment$end$__SEGMENT &...

Hi Nick, Read this along with this example extract: ld -flavor gnu main.o thread.o --start-group libc.a libpthread.a --end-group function.o main.o has atoms ------------------------ main (defined) printf(undefined) fn(undefined) thread.o has atoms ----------------------------- pthread_create (undefined) libc.a(printf.o) has atoms ------------------------------------ printf(defined)

I do think we have too many classes. I thought InputGraph was going to replace InputFiles. It seems link LinkerInput could be merged into FileNode. Originally InputFiles was the abstract interface that he Resolver used to see all the inputs. If InputGraph supported the methods forEachInitalAtom() and searchLibraries() then we could get rid of InputFiles and have the Resolver uses InputGraph

...earchLibraries() then we could get rid of InputFiles and have the Resolver uses InputGraph directly. >>> Yes, this would be nice. I will try to write a proposal in the next few days. >>>> What should the interface be that the Resolver uses for handling groups? >>> bool resolveUndefines(std::vector<File> &files) ? >>> >>> This has to iterate over the files until it reaches a stable point (that no more resolution is possible). >> It is a little more complicated. After initial .o files are processed, there are a bunch of undefines left. The res...

Does LLVM 8 work in macOS 10.9.5? -- Mark

Hi, Attached is the pdf of the operation to make things easier to read. Thanks Shankar Easwaran On 9/20/2013 7:04 PM, Shankar Easwaran wrote: > My email client spoilt the whole email, will create a pdf and send it. > > On 9/20/2013 7:00 PM, Shankar Easwaran wrote: >> Hi Nick, >> >> On 9/20/2013 5:59 PM, Nick Kledzik wrote: >>> On Sep 20, 2013, at 3:42 PM,

...bb2 lld::Resolver::forEachUndefines(lld::File&, std::__1::function<llvm::Expected<bool> (llvm::StringRef)>) + 402 12 ld                       0x000000010e9b7edd lld::Resolver::handleSharedLibrary(lld::File&) + 221 13 ld                       0x000000010e9b85bd lld::Resolver::resolveUndefines() + 1149 14 ld                       0x000000010e9b9af6 lld::Resolver::resolve() + 22 15 ld                       0x000000010e7ba9be lld::mach_o::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&) + 1070 16 ld                       0x000000010e69164f main + 815 17 libdyld.dyl...

Hi, With the inputGraph now, lld models command line options, input files as nodes in the InputGraph called InputElements. In the current approach, each InputElement is converted to a LinkerInput, which works if all lld deals with individual files. Dealing with ControlNodes (Groups), have a problem with it, on how to model that as a LinkerInput. Joerg/Me were chatting on the IRC about this