similar to: Problems using Clang with LLD on embedded ARM

Hi Sean On Sun, Feb 26, 2017 at 5:10 AM, Sean Silva <chisophugis at gmail.com> wrote: > > For that triple, Clang seems to be calling into GCC driver > (/usr/bin/arm-none-eabi-gcc) for linking and GCC doesn't recognize > -fuse-ld=lld (supposedly -fuse-ld=gold selects ld.gold, -fuse-ld=bfd > selects ld.bfd and you would expect -fuse-lld=lld to select ld.lld, but it >

On 28 October 2016 at 17:41, Hans Wennborg <hans at chromium.org> wrote: > There's also -fuse-ld= > > That's how I usually do it. Right, that gets rid of the override flag. Thanks! :) But the arguments about the default and the cross-compilation error still stand. cheers, --renato

On 28 October 2016 at 16:54, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 28 October 2016 at 17:41, Hans Wennborg <hans at chromium.org> wrote: >> There's also -fuse-ld= >> >> That's how I usually do it. > > Right, that gets rid of the override flag. Thanks! :) > > But the arguments about the default and the

>At this point I'm able to link Linux kernel with LLD and objcopy doen't give me any errors. > >The versions are: > >Linux 4.10.0-rc5 (+ applied the patch from my previous message) >LLD 5.0.0 (https://github.com/llvm-mirror/lld db83a5cc3968b3aac1dbe3270190bd3282862e74) (+ applied D28612) >GNU objcopy (GNU Binutils) 2.27 > >The problem is that the resulting

On 28 October 2016 at 18:12, Ed Maste <emaste at freebsd.org> wrote: > It should be possible to search the path for ld.lld first, then ld, > but to me it seems like it will just be more confusing. Hum, for me it would be less confusing. :) GCC uses bfd by default, LLVM uses LLD. If you want to change, use -fuse-ld. What would be confusing in this scenario? > Clang's current

I am linking a program to be loaded in an ARM Cortex-M0+ based microcontroller. In the linker script, I have a section allocated for the stack which roughly looks like the following. .stack : { . += __stack_size__; } > ram Using the linker in the gcc arm toolchain, arm-none-eabi-ld, this section is automatically set to type NOBITS, however, when linking with version 10.0.0 of ld.lld, the

On 23 March 2017 at 21:35, Peter Smith <peter.smith at linaro.org> wrote: > Hello Min, > > This error message occurs when the linker would have to create a > dynamic relocation in a read-only part of the program, which isn't > usually allowed when making a position independent shared-library or > position independent executable. In practice this usually means that >

Hi,   We propose llvm-dwarfutil - a dsymutil-like tool for ELF.   Any thoughts on this?   Thanks in advance, Alexey. ====================================================================== llvm-dwarfutil(Apndx A) - is a tool that is used for processing debug info(DWARF) located in built binary files to improve debug info quality, reduce debug info size and accelerate debug info processing.

I noticed that LLD doesn’t preserve the symbol type for a defsym directive. For example: $ cat f.c void f() {} $ clang -c f.c $ ld.lld -shared --defsym=g=f f.o $ objdump -T a.out DYNAMIC SYMBOL TABLE: 00000000000012a0 g DF .text 0000000000000006 f 00000000000012a0 g D .text 0000000000000000 g f is marked as a function symbol, but g is not. I recognize this is hard to do in the general

Hi While cross compiling on Mac Host: Mac Target: Linux on ArmV7 How can I force clang to use the non-system linker But use llvm-lld (i.e. ld.lld) or any other non standard linker Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180326/d86e1601/attachment.html>

On 26.08.2020 10:58, James Henderson wrote: > In principle, this sounds reasonable to me. I don't know enough about > dsymutil's interface to know whether it makes sense to try to make it > multi-format compatible or not. If it doesn't I'm perfectly happy for > a new tool to be added using the DWARFLinker library. > > Some more general thoughts: > 1)

Hello Christian, I reran my script with a similar cmake command to yours. After the build finished the following command from the build directory gave me: find . -name \*builtins.a ./lib/clang/9.0.0/armv6m-none-eabi/lib/libclang_rt.builtins.a ./lib/clang/9.0.0/armv7m-none-eabi/lib/libclang_rt.builtins.a ./lib/clang/9.0.0/armv7em-none-eabi/lib/libclang_rt.builtins.a I hope you see something like

Hi, I'm trying to build clang/LLVM and am hitting a test failure in compiler-rt/test/safestack/lto.c. I believe the issue is that we've configured clang to use ld.bfd as the linker. ld.bfd has plugin support as described here: https://llvm.org/docs/GoldPlugin.html compiler-rt/test/lit.common.cfg isn't set up to know about ld.bfd: elif config.host_os == 'Linux' and

On Fri, Jan 27, 2017 at 1:31 PM, Rui Ueyama <ruiu at google.com> wrote: > Sean, > > So as you noticed that linker script tokenization rule is not very trivial > -- it is context sensitive. The current lexer is extremely simple and > almost always works well. Improving "almost always" to "perfect" is not > high priority because we have many more high

Hello, I am currently facing an issue at linking stage when compiling basic C code for an embedded PPC32 platform and linking with LLD. For external symbol linkage LLVM appears to use PLT which results in generating a R_PPC_PLTREL24 relocation, that is not support by LDD. Therefore even such a basic example cannot be built: /* s.c */ int f() { return 0; } /* t.c */ int f(); int _start() {

On Tue, Oct 18, 2016 at 8:22 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Oct 18, 2016, at 6:44 PM, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > I'd like to make LLD embed version information so that we can determine > if an executable was created by LLD and if that's the case which version of > LLD. >

The option -fuse-ld is the closest option that I can think of. In its most common form it accepts bfd, gold or lld, clang will then invoke ld.bfd, ld.gold or ld.lld respectively. On many systems ld is a symlink to an executable of the form ld.suffix. Alternatively the full path to the linker can be given -fuse-ld=/full/path/to/linker/executable Peter On 27 March 2018 at 00:40, Sumonto Ghosh via

As I've mentioned before[1] I've been regularly attempting to build the FreeBSD/amd64 base system with lld, in order to keep track of progress and identify issues on an ongoing basis. As of last November a 'buildword' (i.e., userland build) ran to completion, with several workarounds applied to the FreeBSD base system. However, the result did not actually work. I'm pleased to

On Wed, Mar 15, 2017 at 6:02 PM, Ed Maste <emaste at freebsd.org> wrote: > Note that even if/when we get changes incorporated into libtool it > will still take a long time for the change to appear in new releases > of software packages using libtool. A downstream patch to the libtool > package in various operating systems or distributions doesn't really > help that much

Fantastic! Thanks for all of the input! I'll be considering all of it going forward. The plan right now is just to worry about ELF executables and nothing else. I'm very sympathetic to the "llvm-objtool" change. If everyone is cool with it I'll change the name in the next CL to "llvm-objtool". To start out I implemented a very basic ELF64LE specific bit of code.