search for: linkerscripts

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

Hi, I've found a crash in lld when using linker script with wildcard matching. An example linker script: INPUT(os/main.o os/foo.o os/startup.o) OUTPUT(k.bin) SECTIONS { . = 0x0 .text : { *startup.o (.text) } .text.2 : { *(.tex*) } } I've wrote up a patch to fix this crash. Index: tools/lld/lib/ReaderWriter/LinkerScript.cpp <+>UTF-8

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

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

...15, 2015 at 3:34 PM, Celelibi <celelibi at gmail.com> wrote: > Yeah, I'm preparing a port of all the commits that affected > core/syslinux.ld that were not in core/i386/syslinux.ld. If you want > to take a look at it, a WIP version of this is on my github > branch wip/cleanup-linkerscripts. > https://github.com/Celelibi/syslinux/tree/wip/cleanup-linkerscripts > > (Still need a bit of work and testing.) > > Celelibi On Thu, Oct 15, 2015 at 6:50 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > I'd like to try seeing if I can re-merge some of those old com...

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

...range extension thunks for ARM https://reviews.llvm.org/D31662 [ELF] Account for range thunk that has drifted out of range https://reviews.llvm.org/D31663 [ELF] Prefer placing ThunkSections before non ThunkSections https://reviews.llvm.org/D31664 [ELF] Add test cases for range extension thunks (no linkerscripts) https://reviews.llvm.org/D31665 [ELF] Add test cases for range extension thunks using linkerscripts https://reviews.llvm.org/D31666 Peter

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

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

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

...noted the commit 9057b5337c44c08343d403da2a31636dfc1ad741 in my list of lost changes. Yeah, I'm preparing a port of all the commits that affected core/syslinux.ld that were not in core/i386/syslinux.ld. If you want to take a look at it, a WIP version of this is on my github branch wip/cleanup-linkerscripts. https://github.com/Celelibi/syslinux/tree/wip/cleanup-linkerscripts (Still need a bit of work and testing.) Celelibi

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

> As the commit line say, it removes unused linker scripts. This commit > intended to be really dumb: unused = delete. And mbr/mbr.ld isn't > used. I think it's detter delete this one and then move > mbr/i386/mbr.ld to mbr/mbr.ld in a second commit. Which I didn't do > because I wasn't sure of that. > > I didn't delete mbr/x86_64/mbr.ld because I wasn't

Hi all, Which are the command-line options available to pass linker script, library path etc.. to lld? I see minimal options listed, when i say, lld -flavor gnu -help Thanks in advance, -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150209/e7a6f7b8/attachment.html>

Hello Eric, My understanding is that the ADRP instruction isn't supposed to be used on its own. The result of the ADRP provides a 4k aligned address, the following instruction such as an LDR has an immediate offset that can reach any address within the 4k page. For example to get the address of a global variable var with -fpic in ELF: adrp x0, :got:var // relocation

On Mon, Oct 5, 2015 at 2:15 PM, celelibi--- via Syslinux <syslinux at zytor.com> wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > Some linker scripts were splitted into i386 and x86_64 versions in > commit d8eede3f2a360163235fad222a0190cd7c5bef38 but older scripts were > left there. > > Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com>

For example something like STARTUP ( http://wiki.osdev.org/Linker_Scripts#STARTUP) is not accepted by the LLVM LLD. :-/ On Wed, Apr 20, 2016 at 9:08 PM, Sky Flyer <skylake007 at gmail.com> wrote: > Yeah I found it, that's nice. Thanks a milion. > Could you please tell me how can I specify my bootstrap (startup code) in > the linking process? > > > On Wed, Apr 20, 2016

Hi Andrew, Thanks for the background and context. "In your issue, just to clarify, is the ELF output from LLD also "large", or is it just the output from the llvm-objcopy operating on that ELF that is "large"? Do you have a simple sample to demonstrate this issue?" The ELF size is actually smaller, compared to what was generated from LLVM 7.x. (~900Kb vs