similar to: [LLVMdev] [lld] Removal of ELF PowerPC port

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

You are right. LLD does not have this problem. Initially I bumped into the MIPS specific bug related to GP relative relocations calculation. I tried to make reproduction script as general as possible and mistakenly make it too general. So now with your help I realized that the problem solely affects MIPS. On Tue, Sep 27, 2016 at 8:46 PM, Peter Smith <peter.smith at linaro.org> wrote: >

Hi, Now in case of relocatable object generation LLD merges and copies REL/RELA sections as is and does not touch any addends. But it is incorrect. If we have a relocation which targets a section, we have to adjust the relocation's addend to take in account that the section might be merged with other ones. Here is the reproduction script: % cat t1.s .data .long 0 .text bar: movl $1,

Hi, I'd like to experiment with the MIPS and PowerPC backends, but, considering that they aren't widely used processors, I'd like to start with the same environment (OS/ABI/linker) used by the people who work with these backends. So, what OS/ABI/linker use the people who use these backends for production work? Thanks!!

On Wed, May 6, 2015 at 5:30 PM, Daniel Dilts <diltsman at gmail.com> wrote: > > > On Wed, May 6, 2015 at 12:51 AM, Will Newton <will.newton at gmail.com> wrote: >> >> On Wed, May 6, 2015 at 6:22 AM, Chris Lattner <clattner at apple.com> wrote: >> > On May 5, 2015, at 6:47 PM, Daniel Dilts <diltsman at gmail.com> 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 for the writer to tell it must have a way to reach back and ask the atom what type

On 2 October 2013 13:36, Hal Finkel <hfinkel at anl.gov> wrote: > You can certainly do this in terms of an LLVM transformation, but I think > that creating some kind of header file would be, at least, where I'd start > prototyping this. > Yes, this is a good approach to understanding the problem. But I wouldn't use this as a final solution, as it scales quadratically

On Wed, May 6, 2015 at 6:22 AM, Chris Lattner <clattner at apple.com> wrote: > On May 5, 2015, at 6:47 PM, Daniel Dilts <diltsman at gmail.com> wrote: > > Take a look at how debuggers have migrated through the years. They too >> >> used to have their own script format. Now most (all?) popular debuggers >> do scripting through embedding an actual programming

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

----- Original Message ----- > On 2 October 2013 12:17, Renato Golin < renato.golin at linaro.org > > wrote: > > > > > On 2 October 2013 10:12, Steven Newbury < steve at snewbury.org.uk > > wrote: > > > > > > How does this make any sense? > > > I have to agree with you that this doesn't make much sense, but there > is

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

Hi, The LLD linker in gnu flavor mode accepts multiple -init/-fini command line options. For _all_ symbols specified by these options the linker creates appropriate entries in the .init_array/.fini_array sections. But it looks like LD and Gold linkers do not support this feature and take in account only the last -init/-fini options. % cat foo.c int a = 0; void foo() { a += 1; } void bar() { a +=

On Oct 5, 2014, at 9:37 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 5 October 2014 07:19, Saleem Abdulrasool <compnerd at compnerd.org> wrote: >> So with that in mind, I would like to ask, would it be possible to consider >> switching to LLVM style for lld? > > We don't usually enforce code styles on side projects because it > doesn't

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

Is the MIPS backend production-ready for any (or all) of the OSs you mention? As I said, I'd like to start using the MIPS and PowerPC backends with an OS/linker where they are most reliable. In the case of PowerPC, from the comments I conclude there's people successfully using the backend in Linux. OTOH, FreeBSD is "almost there", and not sure about NetBSD and OpenBSD. In the

On 2 October 2013 10:12, Steven Newbury <steve at snewbury.org.uk> wrote: > How does this make any sense? > I have to agree with you that this doesn't make much sense, but there is a case where you would want something like that: when the original source uses NEON intrinsics, and there is no alternative in AltiVec, AVX or even plain C. We encourage people to use NEON intrinsics,

On 2 October 2013 12:17, Renato Golin <renato.golin at linaro.org> wrote: > On 2 October 2013 10:12, Steven Newbury <steve at snewbury.org.uk> wrote: > >> How does this make any sense? >> > > I have to agree with you that this doesn't make much sense, but there is a > case where you would want something like that: when the original source > uses NEON

> On Oct 8, 2014, at 1:55 AM, Renato Golin <renato.golin at linaro.org> wrote: > > On 8 October 2014 05:25, Chris Lattner <clattner at apple.com> wrote: >>> Up until now the thread has been about “formatting”. You suggested renaming >>> every variable in the project! >> >> If that's what it takes. > > If we're still talking about

Hi, Yes, ldd is generating wrong tbss size. It is just considering one tbss section and not calculating all sections from all objects. The following example on x86_64 shows the issue: --- t0.c --- #include <stdio.h> extern __thread int t0; extern __thread int t1; extern __thread int t2; extern __thread int t3; __thread int t4; __thread int t5; __thread int t6; __thread int t7; int