similar to: [LLVMdev] [lld] Allow atoms with empty name in the RefNameBuilder::buildDuplicateNameMap()

I have read ELF specification once again. There is no any explicit references to absolute symbols with no name. The only real case when I see such symbol is a local absolute symbol with "STT_FILE" type. The name of "STT_FILE" symbol is a name of the source file associated with the object file and the "STT_FILE" symbol precedes the other STB_LOCAL symbols from this

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

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

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

Good point. But I suggest to do that by two steps. First, remove TargetLayout and rename DefaultLayout to TargetLayout. Second, merge TargetLayout and Layout. The first step is easy, the second step generates large diff, requires reviewing etc. On Fri, Apr 3, 2015 at 10:40 PM, Rui Ueyama <ruiu at google.com> wrote: > I'm wondering if we even need TargetLayout. > > DefaultLayout

Hi, On Wed, Apr 2, 2014 at 1:03 AM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Mon, Mar 31, 2014 at 10:54 AM, Simon Atanasyan <simon at atanasyan.com> wrote: >> As far as I understand now it is impossible to generate ELF object >> file with relocation sections using yaml2obj tool. I plan to support >> ELF relocations in the yaml2obj. Does anybody work

Hi Galina, I will try to find owners of these buildbots. I hope to get results on the next week. On Sat, Nov 3, 2018 at 1:48 AM Daniel Sanders <daniel_l_sanders at apple.com> wrote: > > Hi Galina, > > I'm sad that they appear to have been abandoned but no objections from me as I'm not the admin for any of these anymore. A couple of them were taken over by a colleague

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.

Hi, Sorry for delay with reply. It looks like now thunks can be implemented as a synthetic sections. In that case we give flexible solution and will be able to put thunks before/after related sections, using different alignment etc. As far as I know BFD linker uses the same approach at least for MIPS thunks. I will try to implement this idea. On Thu, Sep 8, 2016 at 1:44 AM, Rui Ueyama <ruiu

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

Let's suppose that MCLinker folks are here already - I am a committer of this project :). Maybe I did not formulate my suggestion correctly. When I offer to "install" the yaml2obj and obj2yaml utilities I mean result of the "make install" command only. I do not suggest to include this utilities into any distributed binary packages. To be clear I attached the patch with

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

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 Rui, Shankar, Do we really need empty TargetLayout class? No we have the following hierarchy: Layout <- DefaultLayout<> <- TargetLayout<> <- xxxTargetLayout<> I suggest to remove TargetLayout and rename DefaultLayout to TargetLayout. Thoughts? -- Simon Atanasyan

On Wed, Sep 17, 2014 at 10:14 PM, Simon Atanasyan <simon at atanasyan.com> wrote: > Hi, > > Probably you get the error because you try to build LLVM in the source > code directory. Create a separate folder, cd to this folder and run > the configure script. > > $ mkdir llvm-bld > $ cd llvm-bld > $ ../<llvm src>/configure --enable-targets=mips > $ make >

STO_MIPS16 and STO_MICROMIPS flags denote that the symbol use a different "compressed" instructions encoding. Both these flags can be combined with usual "visibility" flags. It looks like adding new flag into the contentTypes set might solve the problem. Thanks for the idea. I try to implement it. On Thu, Nov 6, 2014 at 6:52 PM, Shankar Easwaran <shankare at

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