similar to: [LLVMdev] lld deadstrip atoms

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, 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. Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

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, Thanks for your reply. The usecase here is just trying to construct a valid ELF. The lld linker needs to handle all sorts of code written in assembly as well as 'C'. The usecase is just one example of it. I have also seen similiar code in http://lxr.free-electrons.com/source/arch/powerpc/kernel/head_32.S?a=powerpc which has global and local labels. You are right, that the

Hi Nick, Waiting for your feedback on this. Thanks Shankar Easwaran On 11/16/2012 10:03 AM, Shankar Easwaran wrote: > Hi Nick, > > Thanks for your reply. > > The usecase here is just trying to construct a valid ELF. The lld > linker needs to handle all sorts of code written in assembly as well > as 'C'. The usecase is just one example of it. > > I have also

> On Feb 14, 2018, at 09:55, Steven Wu via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I did a bit more digging for the auto hide problem. Here is my finding that prevent us from doing this by default in GlobalOpts > > 1. When a symbol is linkonce_odr hidden unnamed_addr, it emits both '.private_extern' and '.weak_def_can_be_hidden' asm directives on

On Wed, Feb 14, 2018 at 2:26 PM, Duncan P. N. Exon Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > > On Feb 14, 2018, at 09:55, Steven Wu via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > I did a bit more digging for the auto hide problem. Here is my finding > that prevent us from doing this by default in GlobalOpts > > >

On Nov 11, 2014, at 11:54 AM, Rui Ueyama <ruiu at google.com> wrote: > This falls into the usual topic that whether or not we should have a generic map attached to an atom. You used a reference as an alternative for the map in this case but the basic idea is the same. > > Although using a reference would be practical, it still feels a hack to me. It's awkward at least. Why

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

I had a similar issue with arm vs thumb in mach-o. Each function’s thumbness is marked in its symbol table entry. But it is even worse, a function could change encoding in the middle (only hand coded assembly could do this). My solution was to add a new Reference Kind for mach-o which is the current instruction encoding. The offsetInAtom() is the offset where the encoding kind changes.

Debug info linking is currently broken due to how we handle reading and laying out non SHF_ALLOC sections. I posted a patch that partially fixes this, but it's both the wrong approach and doesn't handle multiple input files with debug info (wrong relocation values). The first issue is representing non SHF_ALLOC atoms in the Atom model. We currently don't have a type for this, and

On Oct 30, 2012, at 3:48 PM, Shankar Easwaran wrote: > Hi Nick, > > Thanks for your reply. > > How about if the atom flags could be overridden ? The Atom flag could have a MIN/MAX and anything above the MAX or lower than the MIN are platform specific, like how its dealt with section indexes ? Can you be more specific in your proposal. What method(s) would you add to the the Atom

Hi Michael, On 9/16/2013 7:23 PM, Michael Spencer wrote: > Debug info linking is currently broken due to how we handle reading and > laying out non SHF_ALLOC sections. I posted a patch that partially fixes > this, but it's both the wrong approach and doesn't handle multiple input > files with debug info (wrong relocation values). > > The first issue is representing non

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:

On 8/22/2013 3:44 PM, Nick Kledzik wrote: > > Linker scripts have the same need. My idea for this was to allow atoms to have an associated expression tree and would have references to all symbols in that tree. The resolver wouldn't need any special handling for this, and the backend would just need to evaluate the expression at the end. > Agreed. > > On one hand, this sounds

Hi Nick, > Can you be more specific in your proposal. What method(s) would you add to the the Atom class(es)? I thought you were thinking of a generic uint32_t DefinedAtom::flags() method where the meaning of each bit in the uint32_t returned was platform specific. How can that work with a min/max range? > The range of flags would be integers ranging from LOW_PROC .. HIGH_PROC. The

On Aug 22, 2013, at 1:32 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Thu, Aug 22, 2013 at 12:54 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > I am planning to work on adding support for definining expressions for the Gnu flavor. > > Currently Gnu ld supports an option --defsym symbol=expression. The expression may be