similar to: [LLVMdev] [lld] [mach-o]: RFC: representing LC_REEXPORT_DYLIB

On Wed, Jul 02, 2014 at 05:09:14PM -0700, Nick Kledzik wrote: > Shankar, Does lld for ELF support loading indirect DSOs? It doesn't, which is a bug. Joerg

On Sat, Jul 05, 2014 at 01:33:11PM -0700, shankarke wrote: > Gnu linker does not support for some reason as well, if we are > emulating the gnu behavior it might be good to handle it in the same way. Binutils broke the ELF behavior with some recent versions. That is not something to follow. Joerg

Hi Nick, On 9/4/2013 4:04 PM, Nick Kledzik wrote: > I do think we have too many classes. Agree. > I thought InputGraph was going to replace InputFiles. Interesting idea. > It seems link LinkerInput could be merged into FileNode. Agree. > > Originally InputFiles was the abstract interface that he Resolver used to see all the inputs. If InputGraph supported the methods

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

Hi Nick, These are the below modifications needed in lld to start processing groups :- 1) LinkerInput would be moved to FileNode that contains the following functions - getBuffer - takeBuffer - getPath 2) The driver will process the vector of InputElements and call /*process */on each of them. process() would create a lld::File object within the InputElement if its a

On Sep 4, 2013, at 2:32 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > On 9/4/2013 4:04 PM, Nick Kledzik wrote: >> I do think we have too many classes. > Agree. >> I thought InputGraph was going to replace InputFiles. > Interesting idea. >> It seems link LinkerInput could be merged into FileNode. > Agree. >> >> Originally InputFiles

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

Hopefully the right list … otherwise pointers appreciated (I’ve spent days trying to find a solution but could not find sufficient documentation, could not find a proper list of -flavor darwin commands) I am setting up an environment for cross compiling shared libraries using LLVM. Overall this works perfectly for many unix like environments but MacOS is a pain in the ass despite that I am

On Sep 4, 2013, at 9:28 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > These are the below modifications needed in lld to start processing groups :- > > 1) LinkerInput would be moved to FileNode that contains the following functions > - getBuffer > - takeBuffer > - getPath > > 2) The driver will process the vector of

Cc'ing people who are working on macOS. On Thu, Apr 27, 2017 at 9:05 AM, Peter Kriens via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hopefully the right list … otherwise pointers appreciated (I’ve spent days > trying to find a solution but could not find sufficient documentation, > could not find a proper list of -flavor darwin commands) > > I am setting up an

On Wed, Sep 4, 2013 at 2:04 PM, Nick Kledzik <kledzik at apple.com> wrote: > 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 >

Shankar, I think your proposal and mine are pretty much the same. The difference is passing back info to the InputGraph as a parameter in nextFile() vs as a separate method call. My original draft email had a parameter in nextFile(), but it seemed a little confusing because the information was referring to the previous file. That is, if the current resolver state has newDefinedAtoms, that

Thanks for the answer. However, this means I need a different linker for MacOS as for Windows/Linux? I guess it is a not a major thing but I was hoping to set up a cross compile env. where only the header files and shared libraries differed :-( I guess we’re not there yet … :-) Kind regards, Peter Kriens > On 6 May 2017, at 19:57, Lang Hames <lhames at gmail.com> wrote: > >

Hey there, lld fails to build on Visual Studio 2013 because of ErrorOr<void>. For example, ErrorOr<void> is used in InputGraph.h as the return type of InputGraph::reset. Inside of ErrorOr, there is: typedef typename remove_reference<T>::type &reference As T is void, and remove_reference <T>::type results in void, the typedef expands to: typedef void & reference,

Shankar and I discussed input file handling, and we came up with a design that may greatly simplify the input file handling, while giving more flexibility to developer to support complicated options, such as --{start,end}-group, -z rescan or -z rescan-now. It'd worth pursuing, so here's the idea: 1. We wouldn't probably want to let Resolver to handle the input graph directly, for we

On Sep 20, 2013, at 3:37 PM, Rui Ueyama <ruiu at google.com> wrote: > On Fri, Sep 20, 2013 at 3:29 PM, Nick Kledzik <kledzik at apple.com> wrote: > Rui, > > I like this in general, but have a few questions. > > On Sep 20, 2013, at 2:30 PM, Rui Ueyama <ruiu at google.com> wrote: > >> 2. We would instead add a new method nextFile() to LinkingContext,

Sounds like a fantastic goal, and enticingly close … Kind regards, Peter Kriens > On 11 May 2017, at 20:53, Andrew Kelley <superjoe30 at gmail.com> wrote: > > Zig author here in the same boat. Looks like I'm going to have to disable cross compiling for MacOS and when compiling native for MacOS add a dependency on the system linker. Really looking forward to Mach-O support

LLD work on Darwin is stalled out at the moment. Patches are welcome (and I'll try to find time to review them), but I'd recommend ld64 for any real-world linking. - Lang. On Thu, Apr 27, 2017 at 11:06 AM, Rui Ueyama <ruiu at google.com> wrote: > Cc'ing people who are working on macOS. > > On Thu, Apr 27, 2017 at 9:05 AM, Peter Kriens via llvm-dev < > llvm-dev

Hi, Right now, linker added symbols specified by the -u option do not endup in the output YAML file. This is because the target specific Writers dont get called, which creates the undefined atoms. I am in the process of adding more options and I would like the atoms created internally by the options available in the output YAML file. The options that I am trying to consider for the linker

On Wed, Sep 04, 2013 at 02:04:14PM -0700, Nick Kledzik wrote: > 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. I both agree and disagree. Logically we have two different views, the command line and the resulting input tree on the side and the groups of object files as seen by the