similar to: [LLVMdev] [lld] Diagnostics

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

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

I think we need a straw man proposal to start iterating on. Clang’s diagnostics has lots of good features. But is has lots that a linker does not need. For instance, the line/column number does not make sense for a linker. Clang errors/warnings are mostly about the source language which is pretty standard across different platforms. Other than multiple-defined and undefined errors, most of

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 7:02 PM, Nick Kledzik <kledzik at apple.com> wrote: > I think we need a straw man proposal to start iterating on. Clang’s > diagnostics has lots of good features. But is has lots that a linker does > not need. For instance, the line/column number does not make sense for a > linker. > Linker scripts will need this (although we still don't really

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 ?

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

Hi, It looks like the the ELFPassFile doesnot get an ordinal value assigned, as its added in a pass. Is there a way to assign a file ordinal for the files added by Passes ? Till that time, I am going to XFAIL the ifunc test. More tests should fail, and am not sure why they are not failing. Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted

On 9/13/2013 6:06 PM, Nick Kledzik wrote: > On Sep 13, 2013, at 3:35 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: >> This would work only if an alias is another name for the same symbol(weak symbols). > I don’t know what that means. Can you clarify? Doesnt this imply that the alias atom is a zero sized atom ? >> If what is being aliased is another function

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

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

On 10/4/2013 11:16 PM, Michael Spencer wrote: > On Fri, Oct 4, 2013 at 8:50 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > >> Hi, >> >> It is needed that lld verifies the input to the linker. >> >> For example : a x86 ELF file can be given to lld when the target is >> x86_64. Similiarly with other flavors. >> >> I was thinking

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

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

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 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

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, 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

> 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

Hi Nick, The problem is when the -emit-yaml option is used, the writer is set to the YAML writer. The YAML writer doesnot have anything to add here. The problem can be solved by having the YAML writer append a list of undefined atoms specified by the -u option, but the problem I have is each flavor has extra command line options for which it wants to create a DefinedAtom/UndefinedAtom. The