similar to: [LLVMdev] [lld] adding deadStrip() to undefined Atoms

On Aug 26, 2013, at 10:20 PM, Shankar Easwaran wrote: > Can we add deadStrip() to undefinedAtoms as well ? > > This will enable to choose whether we want to set the property deadStripNormal or deadStripNever on them. > > Also I think it will be cleaner for atoms to be added to deadStripRoot set using a single API. Can you give more more background on this? When would you want

Hi Nick, On 8/27/2013 12:45 AM, Nick Kledzik wrote: > On Aug 26, 2013, at 10:20 PM, Shankar Easwaran wrote: >> Can we add deadStrip() to undefinedAtoms as well ? >> >> This will enable to choose whether we want to set the property deadStripNormal or deadStripNever on them. >> >> Also I think it will be cleaner for atoms to be added to deadStripRoot set using a

Hi Nick, Dead stripping optimization needs a way to setup the roots which are live. The current code in Resolver does it by 1) setting all the global defined atoms to be the live set when building shared libraries (_options.allGlobalsAreDeadStripRoots) 2) Or, uses a list of names that are dead strip roots (other types) Question:- *********** How are the dead strip root names supposed to be

On Nov 9, 2012, at 10:31 AM, Shankar Easwaran wrote: > Hi Nick, > > Dead stripping optimization needs a way to setup the roots which are live. The current code in Resolver does it by > > 1) setting all the global defined atoms to be the live set when building shared libraries (_options.allGlobalsAreDeadStripRoots) > 2) Or, uses a list of names that are dead strip roots (other

Hi Nick, >> b) Further looking, there is a compiler attribute __attribute(used)__ which could be set for each symbol, but this is only a compiler hint. The information is not passed in the symbol table. If this is not passed in the symbol table to the linker, why is it in the DefinedAtom ? > In mach-o it *is* passed on to the linker by the compiler. It is the N_NO_DEAD_STRIP bit in the

Hi Nick, On 9/20/2013 5:59 PM, Nick Kledzik wrote: > On Sep 20, 2013, at 3:42 PM, Shankar Easwaran > <shankare at codeaurora.org> wrote: >> nextFile could pass the current resolver state at the time when its called, the linkingcontext can return the next file to be processed as below :- >> >> nextFile(currentResolverState) :- >> >> a) Returns the next

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, Shankar Easwaran >> <shankare at codeaurora.org> wrote: >>> nextFile could pass the current resolver state at the time when its >>> called, the

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,

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

Hi Nick, >> The YAML writer does not 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 flavor also may want to add extra linker internal files in

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 Aug 28, 2013, at 3:14 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > The problem is when the -emit-yaml option is used, the writer is set to the YAML writer. Ah! > > The YAML writer does not 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

Hi Nick, In addition to what you mentioned, I think there needs a special *AliasReference* that need to be created which the DefinedAtom points to. Thanks Shankar Easwaran -------- Original Message -------- Subject: Re: [PATCH] Add a fallback mechanism for undefined atom. Date: Thu, 29 Aug 2013 15:15:49 -0700 From: kledzik at apple.com <kledzik at apple.com> Reply-To:

Hi, On Wed, Apr 2, 2014 at 1:03 AM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Mon, Mar 31, 2014 at 10:54 AM, Simon Atanasyan <simon at atanasyan.com> wrote: >> As far as I understand now it is impossible to generate ELF object >> file with relocation sections using yaml2obj tool. I plan to support >> ELF relocations in the yaml2obj. Does anybody work

Hi Nick, On 8/28/2013 6:37 PM, Nick Kledzik wrote > $cat 1.c > int _start() { return 0; } > $gcc -c 1.c > $ld -u myundef 1.o > ==> Does not throw any error, the resolver was hinted that myundef was a undefined weak symbol. > Wow. Reading the gnu ld man page, that is not obvious. How can you make a non-weak undefined on the command line? That is, how can you force and error

On Aug 28, 2013, at 4:24 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > >> Also for the case of -u, the Driver can make generic UndefinedAtoms. > ELF would want to treat the undefined symbols as a weak undefined symbols. So the driver cant create undefined atoms. > > Below is an example :- > > $cat 1.c > int _start() { return 0; }

On 9/23/2013 7:07 PM, Nick Kledzik wrote: > On Sep 23, 2013, at 4:52 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > >> The following code currently links incorrectly when linking against a dynamic libc on Ubuntu 12.10 unless -fpic is specified. >> >> #include <stdio.h> >> >> int main() { >> fputs("hi\n", stdout); >>

On 4/2/2014 12:23 PM, Nick Kledzik wrote: > On Apr 1, 2014, at 9:19 PM, Shankar Easwaran wrote: > >> Hi Nick, Bigcheese, >> >> When lld is used to link C++ code, it would be required to demangle symbol names by default/user driven option. >> >> The Gnu linker has the following options :- >> >> --demangle=[style] >> --no-demangle >>

Hi Nick, Bigcheese, When lld is used to link C++ code, it would be required to demangle symbol names by default/user driven option. The Gnu linker has the following options :- --demangle=[style] --no-demangle I found that clang/llvm-symbolizer use __cxx_demangle function. I would think that lld also need to call the same function, and I think the way we want to demangle is to have the

Can an “alias” atom just be a zero sized atom with one reference of kindLayoutBefore to its target? The layout engine should then place the alias atom right before the real atom, so you wind up with two symbols at one address. -Nick On Sep 12, 2013, at 3:02 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > In addition to what you mentioned, I think there