similar to: [LLVMdev] [lld][failing test] the reason of ifunc.test failing

In addition I think the LayoutPass std::stable_sort be replaced with std::sort as total ordering is guaranteed as each File would get an ordinal and each atom would get an ordinal too, after the below problem is fixed. Thanks Shankar Easwaran On 10/6/2013 10:54 PM, Shankar Easwaran wrote: > Hi, > > It looks like the the ELFPassFile doesnot get an ordinal value > assigned, as its

Ping ? Do you think that we need to have an API in LinkingContext to return the next ordinal available, so that files created by passes can be assigned ordinals ? Thanks Shankar Easwaran On 10/6/2013 11:07 PM, Shankar Easwaran wrote: > In addition I think the LayoutPass std::stable_sort be replaced with > std::sort as total ordering is guaranteed as each File would get an >

On Mon, Oct 7, 2013 at 11:51 AM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Ping ? > > Do you think that we need to have an API in LinkingContext to return the > next ordinal available, so that files created by passes can be assigned > ordinals ? > That API may work, but I don't think you always want to assign the largest file ordinal for a file created in

On 10/7/2013 3:43 PM, Rui Ueyama wrote: > On Mon, Oct 7, 2013 at 11:51 AM, Shankar Easwaran > <shankare at codeaurora.org>wrote: > >> Ping ? >> >> Do you think that we need to have an API in LinkingContext to return the >> next ordinal available, so that files created by passes can be assigned >> ordinals ? >> > That API may work, but I

Hi, I think it would be great if we could subclass the LayoutPass. All the generic functionality could be in the parent to run the layout-after/in-group/ and currently the layout-before passes(until it gets removed). Flavors can *choose to run the layout passes* that they use and determine the way things get ordered in the layout pass. The compare function in the LayoutPass would call

Hi, It looks like the COFF reader creates an Alias atom by adding a kindLayoutAfter reference to the target atom. Now since the kindLayoutAfter passes are moved to machO how does it still work ? Does it work by chance because of ordinals ? I would think moving kindLayoutAfter references and having the LayoutPass would be a better choice. Shankar Easwaran -- Qualcomm Innovation Center,

Hi, I think we are overloading the Layout references for garbage collection. If you are creating a reference (kindLayoutAfter) from A to B, that may not mean that you cannot garbage collect B for the end user. My thought on Layout references was that it only guarantees that atoms appear in Layout reference order. Why are we overloading this for Garbage collection (aside from saving space/code)

Thank you for quick responses! As to dead stripping, if dead stripping is the only pass we need bi-directional edges, we might want the dead stripping pass to construct internal data structure by reversing the graph to construct layout-before edges from layout-after edges. This should be less error prone than maintaining two reverse-directional edges throughout all passes. Of course it will make

In r226336 I shove off 1.2 seconds out of 9.8 seconds for lld to link lld. That's done by parallelizing archive member parsing. But I realized that was not the slowest pass. The single slowest pass in LLD is LayoutPass. Only sort() at the last of Layoutpass::perform takes about 3 seconds (one third of total execution time). It is because the comparison function passed to sort, compareAtoms,

+llvmdev On Fri, Mar 21, 2014 at 3:43 PM, Rui Ueyama <ruiu at google.com> wrote: > Hi all, > > I'm trying to debug an issue that LLD sometimes get into an infinite loop > in setChainRoot() in LayoutPass.cpp. It looks like the cause is either > buildPrecededByTable() handles layoutBefore edges in a wrong way or we > construct a contradictory layout-before/layout-after

Hi, lld doesnot have a Diagnostics interface, It uses llvm::errs() to display errors after linking has been done. I think the Diagnostics interface follow similiar interface patterns as followed by clang (using Diagnostic td files). What do you think ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

On Tue, Jan 8, 2013 at 8:56 PM, <shankare at codeaurora.org> wrote: > Hi Michael, > > Does ELF support aliasing ? > > How is the relationship captured in ELF symbol table, that one symbol is a > alias of another symbol ? It is not explicitly captured. It's an implicit relationship due to the symbols having the same address. > >> Note that __stdout_used is

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

I think having diagnostics interface similar to Clang's would be good. I think the total number of defined warnings would be much smaller than Clang. On Mon, Oct 7, 2013 at 3:19 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Ping ? > > > On 10/4/2013 10:41 PM, Shankar Easwaran wrote: > >> Hi, >> >> lld doesnot have a Diagnostics interface, It

On Mon, Dec 8, 2014 at 8:39 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > On 12/8/2014 11:09 AM, Joerg Sonnenberger wrote: >> >> On Mon, Dec 08, 2014 at 10:21:49AM -0600, Shankar Easwaran wrote: >>> >>> The DT_INIT/DT_FINI correspond to one initializer function,where as >>> DT_INIT_ARRAY/DT_FINI_ARRAY is used when there is more than one

Shankar, The LinkingContext has a addImplictFiles() method that is supposed to call the Writer and give it a chance to add any implicit files. Is the problem that the -u atoms are not attached to that implicit file? Or that the implicit file is not getting added? Or that this got lost in the transition from InputFiles to InputGraph? -Nick On Aug 28, 2013, at 2:44 PM, Shankar Easwaran

Hi Nick, Currently the Reader doesnot have a way to figure out that a file that is being parsed is part of an archive. For linker script support this is needed to match a rule that matches only if the file is from an archive library (or a member of an archive. For example :- SECTIONS { .myoutputsection : { libc.a : { *(.text) } printf.o : { *(.rodata) } } } The colon is used to

On 12/2/2014 11:19 PM, Rui Ueyama wrote: > Do you have to know whether a MemoryBuffer was in a library or not during > parsing that MemoryBuffer? Yes, I need to know that while parsing the buffer too. > > If not, we could just set a library name to a File in > FileArchive::instantiateMember after we call _registry.parseFile. > > On Tue, Dec 2, 2014 at 9:08 PM, Shankar Easwaran

Ping ? On 10/4/2013 10:41 PM, Shankar Easwaran wrote: > Hi, > > lld doesnot have a Diagnostics interface, It uses llvm::errs() to > display errors after linking has been done. > > I think the Diagnostics interface follow similiar interface patterns > as followed by clang (using Diagnostic td files). > > What do you think ? > > Thanks > > Shankar Easwaran

On Mon, Dec 8, 2014 at 10:57 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > The dynamic loader handles only one entry for DT_INIT. If there is more than > one init option, we could convert this as an .init_array instead ? > > If that doesnot work, we can come up with a .init_array option but I am not > sure about how will you handle priority with init_array's ?