similar to: [LLVMdev] [lld] Representation of lld::Reference with a fake target

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

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

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

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

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

Not all input files have to be able to represented in YAML/Native format. There are many unrealistic use cases there. No one wants to write an executable file in Native because there's no operating system that can run that file. So is YAML. So is the combination of .so file and Native/YAML unless we have an operating system whose loader is able to loads a YAML .so file. We might want to write

The ELF relocation record format is different for N64 which many Mips 64 ABIs use than for O64 which many if not all other target ABIs use. The question I have is whether to treat N64 as a valid generic variant or should it be treated as target specific? My contention is that it should be treated as an alternative generic format handled recognized and handled in the ELF class objects above the

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

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 9:06 PM, Shankar Kalpathi Easwaran wrote: > 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. Then we are in agreement. Sid started this thread with the suggestion of adding new content

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

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

When LLD builds a shared library for x86_64 it puts _GLOBAL_OFFSET_TABLE_ to the both .symtab and .dynsym and defines it as a GLOBAL symbol. If later this shared library participates in executable file linking and GNU BFD linked is used for that, this linker shows an error: /usr/bin/ld: a.out: hidden symbol `_GLOBAL_OFFSET_TABLE_' in /usr/lib/x86_64-linux-gnu/crt1.o is referenced by DSO Gold

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 serialize a larger set of atoms, many of which are format specific. The set of common atoms (shared between all formats) should be the set that the resolver requires to work. SharedLibrary is not included in this (by looking at the source

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