search for: armlink

Hi all, libLTO is exposing a very “stable” (in the sense of immutable) C API to be used by linkers (and binutils tools) that manipulate bitcode (like when performing LTO). I’m looking into relaxing the stability concern and design a policy for this API that would allow to deprecate and remove some the APIs exposed here. The MacOS linker (ld64) is one the users of libLTO, but there are others

...le, the LLVM tool chain assumes that every Cortex-A8 has NEON, while the ARM tool chain does not. So, if you compile a file with Clang for Cortex-A8 and link with LLVM linker (or LD), everything works fine, because that assumption is in every step of the tool chain. However, if you try to link with armlink, it won't work, as the NEON attribute (Tag_Advanced_SIMD_arch) will not be there, and when it finds vector instructions, it'll bail out. Another example I quote from the ABI: "The compiler might choose to use only the Thumb ISA in a specific build of a source file. Nonetheless, the r...

Hi Renato, > On 13 November 2010 15:12, Duncan Sands<baldrick at free.fr> wrote: >> I agree that it's limited. As for MC, it will need to handle these strings >> anyway since this is an existing LLVM feature (coming from gcc originally) >> that needs to be supported. > > Do you mean that LLVM-GCC generates build attributes as asm strings in IR? no, I mean

...an omit from the assembly output (initialisation areas are one example of that), but when you start using multiple tool chains to get stuff done, it's better be explicit than rely on "defaults". In that example, for instance, I compiled with clang to IR, llc to asm, gcc to object and armlink to executable. Most of the examples I tested worked fine, but the missing relocation information made it difficult to interoperate. > You probably want dyn_cast<> instead of cast<> so you can do something like: > if (const MCSectionELF* SectionELF = dyn_cast<MCSectionELF>(...

-llvmcommits On Mon, Jan 10, 2011 at 3:21 PM, Renato Golin <renato.golin at arm.com> wrote: > Btw, I know this is for ELF printing, but can the same infrastructure > you're using to print the hi/lo be used to print relocation in Asm > output? Or is this a completely separate subject? Hi Renato, If I am understanding you correctly, then the answer is no, because .s output

...9;s GCC changed a bit on how it works for ARM because the ARM toolchain is a bit more strict in build attributes and relocation information. The static constructor symbol relocation (target1) and exception handling table symbols (prel31) are clearly disregarded by gas and subsequently discarded by armlink. > its also yes because sometimes, the asmwriter will sometimes need to > generate sequences like below > > foo: >   movw r0, :lower16:bar-foo >   movt r0, :upper16:bar-foo > > The subtraction implies that the value bar-foo is implicitly > pc-relative (at least accordin...

Hi, For the following code: void foo (); int main () {foo();} llvm emits "bl foo" Then I set foo at a far address in linking: aarch64-linux-gnu-gcc -Wl,--defsym=foo=0x80000000 a.o -o a.exe I got an error from ld: a.c:(.text+0x8): relocation truncated to fit: R_AARCH64_CALL26 against symbol `foo' define in *ABS* section in a.exe The question is: do I

Is there a way to handle this entirely in the ARM AsmPrinter bits? Adding pieces to the generic MC stuff feels a bit like overkill at first impression. On a minor note: You probably want dyn_cast<> instead of cast<> so you can do something like: if (const MCSectionELF* SectionELF = dyn_cast<MCSectionELF>(Section)) { // ... } -Jim On Jun 16, 2010, at 3:44 PM, Evan Cheng

Sorry, I have been very behind on patch reviews. Bob and Jim, do you have any opinions about this? Evan On Jun 2, 2010, at 5:18 AM, Renato Golin wrote: > Hi, > > Is there any interest in this patch? Is there any better way of doing this (that will be accepted mainstream)? > > I noticed my cast check was wrong (LLVM cast asserts, rather than return a null pointer). Also,

...ain assumes that every Cortex-A8 has > NEON, while the ARM tool chain does not. So, if you compile a file > with Clang for Cortex-A8 and link with LLVM linker (or LD), everything > works fine, because that assumption is in every step of the tool > chain. However, if you try to link with armlink, it won't work, as the > NEON attribute (Tag_Advanced_SIMD_arch) will not be there, and when it > finds vector instructions, it'll bail out. > > Another example I quote from the ABI: > > "The compiler might choose to use only the Thumb ISA in a specific > build of...