similar to: [LLVMdev] [lld] need a way to store the original path for atoms

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

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:

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

On Mon, Apr 20, 2015 at 1:44 AM, Shankar Easwaran <shankarke at gmail.com> wrote: > Attached patch fixes the issue. Thanks for the quick fix. The patch LGTM if you add a test case. Unfortunately yaml2obj does not support duplicated section names but we can use a binary input file. -- Simon Atanasyan

Hi Nick, --start-group/--end-group functionality with the Gnu flavor currently works only if the --start-group/--end-group contains archive files. If they contain dynamic libraries, the undefined atoms from the dynamic libraries are processed whenever the group is iterated again. I am trying to find out a way to make the resolver add undefined atoms from the shared library only *once*, when

Hi Rui, I thought about this, but there is a catch. The undefined symbols still need to be resolved with exports from dynamic libraries even the second time, or any number of times. For example :- ld 1.o --start-group libc.so myprintf.a --end-group 1.o has a undef for myprintf, which is in myprintf.a and myprintf.a calls puts. The first time when libc.so, undef atoms would be added, no

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

Currently, member functions like File::defined() return an iterator for const atoms. But we don't actually treat atoms as consts -- we updates atoms in many places including the core resolver. We have too many const_casts in our code. It just doesn't make sense. I'm making a change to make atoms non-const. Please hit reply if you have any concerns. -------------- next part

I'd do that with the nextFile abstraction like this: On the first iteration, a Group would return its member every time getNextFile() is called (the same as the current behavior). On the second and further iterations, the Group should skip all the members whose type is not Archive. By doing this, the core linker sees dynamic libraries (or regular object files) only once even if they are in

Hi All, I have a design question of how your linker would be suitable for modeling ELF semantics. The ELF linker needs the functionality of reading relocations ahead of symbol resolution for the following usecases :- - Add linker defined symbols if there is a relocation to the symbol (Examples are : defsym, PROVIDE) - Dont halt the linker operation if there are undefined symbols but they are

+ Nick Rui, Does PECOFF writer need the filename in the writer as well, I am not sure if linker scripts are supported with PECOFF though. If PECOFF also needs it, I think it makes sense to store the filename in the Atom as the native format needs to store that information. The only option for the ELF writer to know this information is to use References if other flavors dont need the

Hi Shankar, I almost implement ELFRelocationReader but still not completely sure that this is a right direction. Suppose somebody wants to override creation of the `ELFReference` object from the `Elf_Rela` or `Elf_Rel` record. Let's consider two implementations A and B: A: ===== 1. Factor out `ELFReference` creation from `createDefinedAtomAndAssignRelocations` into a couple of virtual

Nothing wrong with going ahead with a temporary measure if the temporary measure is reasonable (besides the discussion if checking in binary files is desirable). Even if you plan to add a test written in YAML, it's better to check in a binary at least for now than checking it in without any tests. On Mon, Apr 20, 2015 at 7:59 AM, Shankar Easwaram <shankarke at gmail.com> wrote: > I

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

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

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, It looks like the COFF reader creates an Alias atom by adding a kindLayoutAfter reference to the target atom. Now since the kindLayoutAfter passes are moved to machO how does it still work ? Does it work by chance because of ordinals ? I would think moving kindLayoutAfter references and having the LayoutPass would be a better choice. Shankar Easwaran -- Qualcomm Innovation Center,