similar to: LLD symbol types for defsym

Hi all, I am trying to cross-compile my application for ARM Cortex-M3. Here's how I'm doing it: 1, Get a pre-built GNU toolchain for ARM Cortex-M processors from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads 2, Create an object file for ARM: clang -c -target arm-none-eabi -mcpu=cortex-m3 -mthumb -O3 -g

A few days ago, I tried to change the optimization flag from -O0 to -O2 to speed up the execution of the application on Ubuntu/ARM 14.04 32 bit. When I compiled the source code with -O2 flag instead of -O0 flag, I could not run the application normally by getting always the segmentation fault. Here is debugging information with GDB command in case of that. As you can see, we could not execute

I'm attempting to use clang/llvm to compile some legacy C code, and am running into a strange issue. There are several functions in my codebase which make use of the __inline keyword, but do not include the customary static keyword along with it. When I compile these files, the generated code appears not to have any of the function definitions in it--just undefined references to external

On Wed, 4 Dec 2019 at 07:05, Fāng-ruì Sòng <maskray at google.com> wrote: > > On Tue, Dec 3, 2019 at 7:02 PM Shoaib Meenai via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > LLD treats any symbol referenced from a linker script as a GC root, which makes sense. Unfortunately, it also processes --defsym as a linker script fragment internally, so all target

LLD treats any symbol referenced from a linker script as a GC root, which makes sense. Unfortunately, it also processes --defsym as a linker script fragment internally, so all target symbols of a --defsym also get treated as GC roots (i.e., if you have something like --defsym SRC=TGT, TGT will become a GC root). I believe this to be unnecessary for defsym specifically, since you're just

I have made some further investigation. My conclusion is that GNU ld does not do better than lld. Making the --defsym behavior ideal is difficult in the current framework. GNU ld has some unintended behaviors. ld.bfd a.o --defsym 'd=foo' --gc-sections -o a => GNU ld retains .text_foo ld.bfd a.o --defsym 'd=foo+3' --gc-sections -o a => GNU ld drops .text_foo ld.bfd a.o

On Wed, 15 Apr 2020 at 03:36, John Brawn <John.Brawn at arm.com> wrote: > > > Could you please point out what am I doing wrong in the patch ? > > It's because you're getting the function name by doing > callee->getName().str().c_str() > The str() call generates a temporary copy of the name which ceases to exist outside of this expression > causing the

Hi Mayur, > On 24 Nov 2014, at 07:00, MAYUR PANDEY <mayur.p at samsung.com> wrote: > In the assembly generated with O0, we are getting the "blx" instruction whereas with O1 we get "bx" (in 3.4.2 we used to get "blx" for both O0 and O1). > > Is this because of this patch: [llvm] r214959 - ARM: do not generate BLX instructions on Cortex-M CPUs

I’m tying to run a rust application on armv4 architecture (arm720tdmi). Rust is using llvm to generate native code. Some programs are running well on the target but for more complex applications I receive a Illegal instruction : gdb disassembling the core dump file gives : 0x401e41dc <+0>: push {r11, lr} 0x401e41e0 <+4>: mov r11, sp 0x401e41e4 <+8>: sub sp, sp, #8

Hello, here is a patch to add Thumb call relocation to the dynamic linker. I would be happy if you could commit it to the SVN. Thank you, Jonas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130524/069287d6/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed...

So you see the issue as well in ARM? When doing a objdump -D weakMainO1.exe | grep -A 10 "<_ZN1C13caller_methodEv>:" I see: 00008b88 <_ZN1C13caller_methodEv>: 8b88: e92d4800 push {fp, lr} 8b8c: e1a0b00d mov fp, sp 8b90: e24dd008 sub sp, sp, #8 8b94: e58d0004 str r0, [sp, #4] 8b98: e59d0004 ldr r0, [sp, #4] 8b9c: ebffdd17 bl 0

On 14/07/2020 03:27, David Blaikie via llvm-dev wrote: > (+Richard - it's handy to include folks from previous discussions > explicitly so everyone can more easily keep track of the conversation) > > On Mon, Jul 13, 2020 at 6:17 PM Fangrui Song via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Sometimes it is

Hi Jonas, > here is a patch to add Thumb call relocation to the dynamic linker. I would be happy if you could commit it to the SVN. Thanks very much for working on this. It looks like a good starting-point, but there are a couple of issues with the patch at the moment. First, it only handles RelValue up to 22 bits (depending on how you count) in size. But on ARMv6T2 onwards the J1 and J2

Michael Johnson via llvm-dev <llvm-dev at lists.llvm.org> writes: > Hi Rui, > > Are there any plans to support the -defsym command line option? It doesn't look that hard, it was just never requested. What project is using it? Cheers, Rafael

As reported in an earlier thread (http://clang-developers.42468.n3.nabble.com/Disable-memset-synthesis-tp4057810.html), we noticed in some cases that the llvm.memset intrinsic, if lowered to stores, could help with performance. Here's a test case: If LIMIT is > 8, I see that a call to memset is emitted for arm & aarch64, but not for x86 target. typedef struct { int v0[100]; }

Hi Nick, I am planning to work on adding support for definining expressions for the Gnu flavor. Currently Gnu ld supports an option --defsym symbol=expression. The expression may be composed of other symbols. Any symbol that appears in the expression, gets its value from the output symbol value (address of the symbol in the output file). In addition the symbol only gets defined if and only

Thanks for your prompt reply. I didn't build the libc at all, I downloaded a pre-built version of the whole toolchain from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads, so I guess it is an official version provided by ARM and should work? This version targets ARM Cortex-M and Cortex-R family of processors... Son Tuan Vu On Mon, Mar 12, 2018 at 4:15 PM, Tim Northover

Hi, I have attached WIP patch for adding foldMemoryOperand to Thumb1InstrInfo. For the following case: void f(int x, int y, int z) { void bar(int, int, int); bar(x, y, z); bar(x, z, y); bar(y, x, z); bar(y, y, x); } it calls foldMemoryOperand twice, and thus converts two calls from blx to bl. callMI->dump() shows the function name "bar" correctly, however in generated

On Wed, Jan 2, 2013 at 2:53 PM, Nick Kledzik <kledzik at apple.com> wrote: > The SECTION and MEMORY seem doable in lld as part of the ELF > Writer. MEMORY and most aspects of SECTIONS are effectively syntax sugar and the rest of LLD doesn't need to even be aware of it; the ldscript language processor will desugar it. The same is true of many other linker script constructs that I

splited patches and test cases mc-elf-thumbfunction-bit.diff: for 1 mc-elf-arm-backend-bl-blx-sign-bit.diff: for 2. mc-elf-thumb-bl-blx-relocation-table-entry.diff: for 3. mc-elf-cpu-xscale-attributes.diff: for 4. elf-thumbfunc.s: test case for 1 elf-thumbfunc-reloc.ll: test case for 2 and 3 elf-xscale-attribute.ll: test case for 4 On Fri, May 13, 2011 at 1:42 PM, Koan-Sin Tan <koansin.tan