similar to: [LLVMdev] [lld] Handling non SHF_ALLOC sections.

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

On Mon, Sep 16, 2013 at 6:48 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > 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

On Mon, Sep 16, 2013 at 8:23 PM, Michael Spencer <bigcheesegs at gmail.com>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

On Sep 16, 2013, at 6:48 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > 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

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,

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

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, Thanks a lot for your answer. It seems lld is still the best solution, even if it does not work "right out of the box" for us today. We already have a solution for the "objcopy" part (added the required output format to llvm-objdump). The ScriptLayout class seems to be empty for now (on the master branch at least), but we do not need linker scripts today. All that is

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

Hi Nick, Can we add a atomContentHash for DefinedAtoms when the atoms are being created. This can essentially speed up comparisons of atoms especially for * ICF (Identical code folding) * Section groups (to identify similiar sections) Not sure where else this would help. This would essentially be used only by the Reader and the Resolver. There would be no change to 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

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

Shankar, Do you mean add a method like: virtual unsigned contentHash() const = 0; or maybe: virtual llvm::hash_code contentHash() const = 0 to lld::DefinedAtom? That seems good to me. We just need to figure out what should happen with atoms not intended to be merged. Should the method assert? In the case where we want there to be a hash available, is it computed lazily?

On Aug 22, 2013, at 6:42 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > 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

On Tue, May 7, 2013 at 10:08 PM, Nick Kledzik <kledzik at apple.com> wrote: > Shankar, > > Do you mean add a method like: > > virtual unsigned contentHash() const = 0; > > or maybe: > > virtual llvm::hash_code contentHash() const = 0 > > to lld::DefinedAtom? That seems good to me. We just need to figure out > what should happen with atoms not

Thanks for the reply Nick. I will use the Writer::addFiles functionality. Do you want to move the SimpleFile class to lld/Core ? It might be useful for other types of object files too(like for ELF here). How does typeFirstInSection/typeLastinSection know that the addresses that need to be used for those symbols are the symbol values for the section start / section end ? I didnt see

Hi, I need an advice on implementation of a very specific kind of relocations used by MIPS N64 ABI. As usual the main problem is how to pass target specific data over Native/YAML conversion barrier. In this ABI relocation record r_info field in fact consists of five subfields: * r_sym - symbol index * r_ssym - special symbol * r_type3 - third relocation type * r_type2 - second relocation type

Hi Nick, This would work only if an alias is another name for the same symbol(weak symbols). If what is being aliased is another function definition, which is a non zero sized atom, aliasing will not work. I was thinking to model this for ELF for the below functionalities :- a) __wrap For example : --wrap fn What I plan to do here is, create a undefined function fn atom create a defined