search for: linkerscript

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 rewritten. Best regards, Rafael Auler On Fri, Aug 21, 2015 at 8:48 PM, Davide Italiano <davide at freebsd.org> wrote: &...

...d 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 =================================================================== --- tools/lld/lib/ReaderWriter/LinkerScript.cpp (revision 8570c61c3fce7de2f655a20f8b184efa1bd97c00) +++ tools/lld/lib/ReaderWriter/LinkerScript.cpp (revision ) @@ -2557,7 +2557,7 @@ switch (*j) {...

...7a20281bf063f659d74f86c127ea1 Author: Andrew Kelley <superjoe30 at gmail.com> Date: Fri Dec 1 12:08:16 2017 -0500 LLD patch: Fix for LLD on linker scripts with empty sections This reapplies 569cf286ff79a10126b9f20f39fa8c64df9b8b25 to the embedded LLD. diff --git a/deps/lld/ELF/LinkerScript.cpp b/deps/lld/ELF/LinkerScript.cpp index 8bdbd8db..614f5e2c 100644 --- a/deps/lld/ELF/LinkerScript.cpp +++ b/deps/lld/ELF/LinkerScript.cpp @@ -751,7 +751,7 @@ void LinkerScript::adjustSectionsAfterSorting() { if (auto *Cmd = dyn_cast<OutputSectionCommand>(Base)) { Cmd->MemRegi...

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(CO...

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

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 would make much sense. However, it may provide a legitimate shortcut to a solution which doesn...

...d thunks - We have moved the createThunks() function as late as it can be in finalizeSections(), most importantly after all the content has been added to the image. - We only call createThunks() once and we don't calculate addresses before createThunks(). - If an OutputSection is described by a LinkerScript then any thunks created in it are put at the end of the OutputSection. This is due to the LinkerScript not being aware of the thunks (InputSections) in the InputSectionDescriptions. Proposed implementation for range extension thunks At a high-level we need to solve the following problems: - Assign...

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

...ter On 21 May 2018 at 14:23, Eric Gorr via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 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 would make much sense. However, it may provide a legitimate > shortcut to a...

...e 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 LinkerScript. But we need to careful not to hurt performance by doing that. On Wed, Apr 5, 2017 at 4:14 PM, Rafael Espíndola via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > Proposed implementation for range extension thunks > > At a high-level we need to solve the following problems: &...

...;> >> It is actually not relative with ASSERT. LLD does not support "symbol = >> 5*6", but accepts "symbol = 5 * 6" currently. >> Not sure what is easy fix here. >> > > I'm not sure if it is easy, but I think that it's clear that the > linkerscript lexer needs to be improved. I think that is the source of the > problems with `*(.apicdrivers);` as well. > Actually, quickly staring at the code, the `*(.apicdrivers);` seems like it will be lexed correctly. -- Sean Silva > This is not the first bug related to lexing that we have run...

...executable, the symbol will be removed by `--gc-sections` when the linker sees no reference to it. It appears that the only way to keep an unreferenced symbol while linking with `--gc-sections` (compiling with `-f{function,data}-sections`) is to put it in a segment that is kept as specified by the linkerscript (`KEEP`). I hope someone can tell me that my current understanding is correct, and that we have to use another way to keep a symbol until the very end (tips welcome, without modifying the system default linker script...). Thanks! Johan -------------- next part -------------- An HTML attachment...

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

...ter On 21 May 2018 at 14:23, Eric Gorr via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 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 would make much sense. However, it may provide a legitimate > shortcut to a...

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

...commit ccba42c7eb3cdfe7824cd4b473a9688e5738fa3a was to > fix an issue that was causing incorrect segment file offset alignment > for any non-empty segment that happens to start with a section that > only contains symbols and no other content. If you look at the test > case "ELF/linkerscript/symbol-only-align.test" that might help > demonstrate the situation. This particular issue actually resulted in > invalid ELF output. > > I don't remember all the details, but at the time, this was the > simplest fix given the code at that point. The alternatives would ha...