search for: absoluteatoms

I think that absolute atoms will need something similar to, "contentType" added. SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order for the writer to tell it must have a way to reach back and ask the atom what type of symbols caused it to be created. To that end I added a contentType method to AbsoluteAtom and sprinkled changes around to

On Oct 15, 2012, at 8:08 AM, Sidney Manning wrote: > > I think that absolute atoms will need something similar to, "contentType" added. > > SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order for the writer to tell it must have a way to reach back and ask the atom what type of symbols caused it to be created. To that end I added a

...ation that when its STT_FILE and the symbol name is the name of the translation unit already. > > I dont think the linker has to add a absolute symbol by figuring out the translation unit. Then we are in agreement. Sid started this thread with the suggestion of adding new content types to AbsoluteAtoms so as to encode STT_FILE symbols. I said we don't need to new content type, but rather that STT_FILE should map to the lld::File's translationUnitSource instead of to an Atom. -Nick > > Shankar Easwaran > > On Mon, Oct 15, 2012 at 6:07 PM, Nick Kledzik <kledzik at apple....

Hi Nick, The object file already has the information that when its STT_FILE and the symbol name is the name of the translation unit already. I dont think the linker has to add a absolute symbol by figuring out the translation unit. Shankar Easwaran On Mon, Oct 15, 2012 at 6:07 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Oct 15, 2012, at 4:00 PM, Sid Manning wrote: >

On Oct 15, 2012, at 4:00 PM, Sid Manning wrote: > On 10/15/12 12:01, Nick Kledzik wrote: >> >> On Oct 15, 2012, at 8:08 AM, Sidney Manning wrote: >>> >>> I think that absolute atoms will need something similar to, "contentType" added. >>> >>> SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order

On 10/15/12 12:01, Nick Kledzik wrote: > > On Oct 15, 2012, at 8:08 AM, Sidney Manning wrote: >> >> I think that absolute atoms will need something similar to, "contentType" added. >> >> SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order for the writer to tell it must have a way to reach back and ask the atom what type

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

Can we remove Native format support? I'd like to get input from anyone who wants to keep the current Native format in LLD. On Thu, Feb 5, 2015 at 2:03 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > The only way currently is to create a new reference, unless we can think > of adding some target specific metadata information in the Atom model. > > This has come up

I'm not planning to remove YAML. YAML is important for testing. On Fri, Feb 6, 2015 at 3:57 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > I am fine with it. I hope you are not planning to remove YAML. > > > On 2/6/2015 4:54 PM, Rui Ueyama wrote: > > Can we remove Native format support? I'd like to get input from anyone who > wants to keep the

...rather than having the symbols seperately considered in the Driver, on whether we want to add to the deadStripRoot set or not, we can just use the attributes on the atom to place them in the deadStripRoot set / not. On the similiar lines, I think it should become an atom property itself (having absoluteAtoms also have this property set) ? What do you think ? Thanks Shankar Easwaran -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130827/1ce82f84/attachment.html>

There are two questions. Firstly, do you think the on-disk format needs to compatible with a C++ struct so that we can cast that memory buffer to the struct? That may be super-fast but that also comes with many limitations. It's hard to extend, for example. Every time we want to store variable-length objects we need to define string-table-like data structure. And I'm not very sure that

A bit off topic: ARM Group relocations define a logical set of consequent instructions to be relocated to form one single address. For such relocations a 1 to 1 relation is also met, so no need of special processing in applyRelocation. Concerning native format: it also introduced unneeded code complexity to me when I wanted to set calculated relocation addend back into the Reference object in the

On Fri, Feb 6, 2015 at 5:42 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Fri, Feb 6, 2015 at 5:31 PM, Rui Ueyama <ruiu at google.com> wrote: > > There are two questions. > > > > Firstly, do you think the on-disk format needs to compatible with a C++ > > struct so that we can cast that memory buffer to the struct? That may be > >

I think no one is opposing the idea of reading and writing YAML. The problem here is that why we need to force all developers to write code to serialize intermediate data in the middle of link, which no one except the round-trip passes needs. On Fri, Feb 6, 2015 at 6:41 PM, Shankar Easwaram <shankarke at gmail.com> wrote: > Doing it for every input file is not useful as some of 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

Hi, The round trip passes just tries to load a *complete* object file in YAML/Native format back. The internal state should be the complete object file in native/yaml format. If some state is not recorded and that is really needed in the writer, we should add that to the Atom model. Shankar Easwaran On 2/9/2015 1:29 PM, Rui Ueyama wrote: > I want to bring this again because I think

Hi Nick, We have few symbols like __bss_start, __bss_end, which are Undefined symbols in the code. I want a way in the Reader to create specific atoms before the linker bootstraps. I didnt find a way to do that with the existing interfaces. The way it needs to work is as below :- 1) ReaderELF creates Absolute symbols (for __bss_start, __bss_end etc) 2) ReaderELF reads each file and adds

On Jul 18, 2012, at 3:41 PM, Clow, Marshall wrote: > On Jul 18, 2012, at 2:34 PM, Nick Kledzik wrote: >> On Jul 18, 2012, at 12:52 PM, Michael Spencer wrote: >>> I've run into some issues with the current atom object model that I >>> would like to fix. >>> >>> The current 4 atoms are not expressive enough. We need to be able 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

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