similar to: a lld linker script bug

Hi, Thanks for your patch, Huang. It looks good to me. Just one comment: can you write a testcase, similar to the others used for linker script testing, with your example? Alternatively, you can modify lld/test/elf/linkerscript/sections-with-wildcards.test to test your case. This will make your patch complete and ready for commit, and will ensure we do not regress on this bug if this code is ever

Zig tests using Debug build of 5.0.1rc2 hit this bug: https://bugs.llvm.org/show_bug.cgi?id=34452 I suppose the fix has not been backported to 5.0.1. So I created a Release build of 5.0.1rc2 and all zig tests pass, with the following patches: * Patches to LLD: commit a206ef34bbbc46017e471063a4a1832c1ddafb0a Author: Andrew Kelley <superjoe30 at gmail.com> Date: Fri Dec 1 12:11:55 2017

Hi, I've tagged the 5.0.1-rc2 release, go ahead and start testing and report your results. -Tom

Thank you for providing the explanation for how ADRP works...something I should have done myself. With this explanation in hand, one other alternative I was looking at was using a linkerscript to essentially rebase the code and have ADRP instructions that would address the correct location as a result. However, I am not a linkerscript expert, so I am not sure if such a thing is even possible or

This RFC is primarily to support the review of the range extension thunks implementation of lld. This concerns ARM and Mips as all of the thunk creation step is skipped over if the target doesn't need thunks. Mips LA25 Thunks are not range extension Thunks but these are generated using the same code, I've kept the behaviour the same as it is now, although the implementation is obviously

Hello Eric, If you do decide to investigate the linker script route, the ALIGN builitin function might be useful. I think the simplest way is to do something like: .text ALIGN(0x1000) : { *(.text) } .my_next_section ALIGN (0x1000) : { *(my_next_section) } Bothe .text and .my_next_section would start at 4k boundaries. Link to docs:

Are you suggesting other linker jobs such as creating _end symbols to the linker script? The linker script support was implemented after we wrote the current Writer class, so it is somewhat "plugged in" to the Writer. It might not be the best design, and not many other options have been explored. So there might be room to improve code by moving work loads from the Writer to the

On Fri, Jan 20, 2017 at 12:44 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, Jan 20, 2017 at 8:35 AM, George Rimar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Dmitry, >> >> thanls for sharing. Few comments/questions below: >> >> >Here is the list of modifications I had to do in order to link the >>

I wonder what is correct way to create PT_LOADs when linkerscript is used ? Currently we create new one for each section that changes access flags. But ld seems to do different thing. Imagine we have next sections: .section .AX.1,"ax" .quad 1 .section .A.1,"a" .quad 2 .section .AW.1,"aw" .quad 3 And script: SECTIONS { . = ALIGN(CONSTANT (MAXPAGESIZE)); .AX : {

Hi all, The documentation of `@llvm.used` says: "If a symbol appears in the @llvm.used list, then the compiler, assembler, and linker are required to treat the symbol as if there is a reference to the symbol that it cannot see (which is why they have to be named)." We've always understood this as: the symbol will survive into the final executable, also when it is in its own

On Tue, Jan 20, 2015 at 6:06 PM, Rui Ueyama <ruiu at google.com> wrote: > On Tue, Jan 20, 2015 at 5:42 PM, Chandler Carruth <chandlerc at google.com> > wrote: > >> >> On Tue, Jan 20, 2015 at 5:35 PM, Nick Kledzik <kledzik at apple.com> wrote: >> >>> On Jan 19, 2015, at 6:33 PM, Chandler Carruth <chandlerc at google.com> >>>

On Tue, Jan 20, 2015 at 5:35 PM, Nick Kledzik <kledzik at apple.com> wrote: > On Jan 19, 2015, at 6:33 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > > I wanted to go through and map out the layering of LLD's libraries today > and found that it's essentially impossible. I think some serious cleanup is > needed here. > > > >

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\concrt.h(313): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc (C:\lld-x86_64_win7\lld-x86_64-win7\llvm.src\tools\lld\lib\ReaderWriter\ELF\Hexagon\HexagonLinkingContext.cpp) [C:\lld-x86_64_win7\lld-x86_64-win7\llvm.obj\tools\lld\lib\ReaderWriter\ELF\Hexagon\lldHexagonELFTarget.vcxproj]

I wanted to go through and map out the layering of LLD's libraries today and found that it's essentially impossible. I think some serious cleanup is needed here. Let's start with the purely link-level dependencies encoded in the CMake build: Curently the Core library depends on the ReaderWriter/Native library, which links against the ReaderWriter library, which links against the Core

Hi, I'm analysing the LLD code structure (aka architecture) and am trying to mold it into a component model. Currently I see 4 components: - Driver - ReaderWriter - Passes - Core I wonder if this is the order that they're supposed to be in, since there are also code dependencies upwards from: Core -> ReaderWriter Passes -> ReaderWriter ReaderWriter -> Driver For a

On 21 May 2018 at 13:57, Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> wrote: > "ADRL produces position-independent code, because the address is calculated > relative to PC." > > From this, I'd expect ADRP to simply do Xd <- PC + n*4096, where n is a 20 > bit number, just like AUIPC in RISC-V (also a 20 literal multiplied by 4096) > or AUIPC in MIPS

On Sun, Oct 6, 2013 at 8:21 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > C:\Program Files (x86)\Microsoft Visual Studio > 11.0\VC\include\concrt.h(313): warning C4530: C++ exception handler used, > but unwind semantics are not enabled. Specify /EHsc > (C:\lld-x86_64_win7\lld-x86_**64-win7\llvm.src\tools\lld\** >

Hi, I've been following the changes in LLD's software architecture. Recently a new file was added: Alias.h In this file, the curret Atom set is extended with an AliasAtom. While the change seems innocent enough, it has some nasty potential. Simple.h and Alias.h are placed in the ReaderWriter component. This is the 2nd component in the layering: Driver ReaderWriter Passes Core The problem

The inverted dependency of Core to ReaderWriter via Simple.h was already present. My idea was to fix the problem before it gets bigger. My proposal would be to move Simple.h and Alias.h to Core. Similar to UndefinedAtom.h etc. It would be even nicer to make the naming consistent as well, since there already is UndefinedAtom.h SharedLibaryAtom.h etc Maybe: SimpleAtom.h AliasAtom.h Moving the file

On Mon, Jun 2, 2014 at 12:49 AM, Rui Ueyama <ruiu at google.com> wrote: > I agree to move these files to Core. Any objections? None here. - Michael Spencer > > On Mon, Jun 2, 2014 at 12:44 AM, Bas van den Berg > <b.van.den.berg.nl at gmail.com> wrote: >> >> The inverted dependency of Core to ReaderWriter via Simple.h was already >> present. >> My