similar to: PIC and mcmodel=large on x86 doesn't use any relocations

> > Message: 2 > Date: Sat, 29 Oct 2016 22:36:41 +0200 > From: Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> > To: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] PIC and mcmodel=large on x86 doesn't use any > relocations > Message-ID: <20161029203641.GB20270 at britannica.bec.de> > Content-Type: text/plain; charset=us-ascii >

We're at the point in our port of OpenVMS to x86 using LLVM to make choices on mcmodel. Given OpenVMS's history, our linker will allocate static data (ie, .data, .bss, .plt, GOT, etc.) in the bottom 32-bits of address space (ie, 00000000.xxxxxxxx). However, we support code anywhere in the 64-bit address space as PIC code (we do this on Itanium today using our own code-generator and

> > Message: 3 > Date: Thu, 27 Oct 2016 17:12:53 -0400 > From: John Reagan via llvm-dev <llvm-dev at lists.llvm.org> > To: <llvm-dev at lists.llvm.org>, <llvm-dev-request at lists.llvm.org> > Subject: Re: [llvm-dev] PIC and mcmodel=large on x86 doesn't use any > relocations > Message-ID: <00cf01d23096$e1e14430$a5a3cc90$@net> > Content-Type:

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 Sat, 2012-04-28 at 15:51 -0500, Hal Finkel wrote: > > > - There is no support for generating position-independent code on > > > PPC32. (PIC on PPC64 now works well). Nevertheless, I have > > > sometimes run into linking errors when compiling shared libraries > > > with C++ on PPC64. PPC64 is PIC by nature. As for the linking issue, possibly you blew the

Hal, I very well understand that LDD may not be in a good state for PPC32, and it would definitely need some improvements sooner or later. In fact I even submitted a patch adding a relocation to ldd just a few hours ago. However, this particular case is not related to LDD, it is a design issue and furthermore a regression in LLVM itself. I checked gcc, and neither does it try to use PLT and

Hi, I'm in the process of migrating from clang5 to clang10. Unfortunately clang10 introduced a negative performance impact. The cause is an increase of PLT entries from this patch (first released in clang7): https://bugs.llvm.org/show_bug.cgi?id=36370 https://reviews.llvm.org/D43383 If I revert that clang patch locally, the additional PLT entries and the performance impact disappear. This

Splitting the previous serie in two. This part contains assembly code changes required for PIE but without any direct dependencies with the rest of the patchset. Changes: - patch v8 (assembly): - Fix issues in crypto changes (thanks to Eric Biggers). - Remove unnecessary jump table change. - Change author and signoff to chromium email address. - patch v7 (assembly): - Split patchset

Splitting the previous serie in two. This part contains assembly code changes required for PIE but without any direct dependencies with the rest of the patchset. Changes: - patch v8 (assembly): - Fix issues in crypto changes (thanks to Eric Biggers). - Remove unnecessary jump table change. - Change author and signoff to chromium email address. - patch v7 (assembly): - Split patchset

Hello, I'd like to introduce myself, my company, and our upcoming use of LLVM. My name is John Reagan. I've been working on compilers and assemblers since 1983 (yes, 31 years). Most of that time was spent on compilers for VAX/VMS (later renamed to OpenVMS), then OpenVMS on Alpha, and OpenVMS on Itanium. I've also worked with the HP NonStop platform and was directly involved

Hi Rafael, Yes, merging gv prevents linker to do garbage collection. Should it be implemented as a peephole pass? If we do it too early, the distance between GVs are not fixed yet. PS: Below is the GCC output with "extern" hidden: ldr r2, .L2 stmfd sp!, {r3, lr} .save {r3, lr} .LPIC0: add r0, pc, r2 bl _Z4initPv(PLT) ldr r1, .L2+4 .LPIC1: add r0, pc, r1 bl _Z4initPv(PLT) ldr

On Tue, 01 May 2012 15:10:56 -0500 Peter Bergner <bergner at vnet.ibm.com> wrote: > On Sat, 2012-04-28 at 15:51 -0500, Hal Finkel wrote: > > > > - There is no support for generating position-independent code > > > > on PPC32. (PIC on PPC64 now works well). Nevertheless, I have > > > > sometimes run into linking errors when compiling shared > >

> You used -noinhibit-exec to ignore the diagnostic, which is usually a bad thing. I certainly agree with that. The point I was trying to make in my original email is that, specifically for kernel objects, this diagnostic is incorrect. R_X86_64_PC32 can be used safely against the symbol foo in that specific context, and should be possible without ignoring diagnostics. I wondered if there

Hello, Rafael > On linux X86_64, calls to local but externally visible functions > should use the PLT. Access to local (same compilation unit), variables > can just use RIP relative access. Right, this is just optimization. AFAIR, current code already does this for 'normal' PIC - it just checks for linkage and doesn't assemble call via PLT for stuff with internal linkage.

Hi, We are trying to use LLVM API to programmatically obtain a list of relocations in an ELF file. The way we are doing this is exactly as llvm-objdump does it: we are iterating through sections and in each section we are iterating over relocations (see PrintRelocations() function at https://llvm.org/svn/llvm-project/llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp). However, it does not give us

Commit-ID: cb90a942dcb20ca34ea6d7b2f3df80d28378d871 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=cb90a942dcb20ca34ea6d7b2f3df80d28378d871 Author: Anton Blanchard <anton at samba.org> AuthorDate: Tue, 3 Dec 2013 18:19:06 +1100 Committer: H. Peter Anvin <hpa at zytor.com> CommitDate: Tue, 3 Dec 2013 10:53:31 -0800 [klibc] ppc64: build with -mcmodel=small

Yes. We currently build LLVM 3.4.2 on our OpenVMS Itanium box with an older EDG/Intel C++03 compiler to create legacy cross-compilers to our OpenVMS x86 box (well, VirtualBox). We do have a few tweaks to the relocations to access static data always through the GOT (including CodeGen's static data). Our linker sees references to code (which might be in 64-bit space) and creates trampolines

If available, use -mcmodel=small. klibc is small enough that we should never hit the limits of the small memory model. This produces better code, for example: 000000000f003890 <.strcasecmp>: f003890: 3c a2 ff fe addis r5,r2,-2 ... f003898: 38 c5 23 58 addi r6,r5,9048 ... f0038ac: 7d 46 50 ae lbzx r10,r6,r10 vs: 000000000f0037c4 <.strcasecmp>:

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of JF > Bastien via llvm-dev > Sent: Thursday, June 13, 2019 12:25 PM > To: John Reagan > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] Coding Standards: "prefer `int` for, regular > arithmetic, use `unsigned` only for bitmask and when you, intend to

Hello all, I'm developing a hobby kernel for x86-64 machines, and I put the kernel into the higher half. I'm trying to switch from GCC to LLVM/Clang, but it seems that the latter doesn't support the -mcmodel=large option, which is required in order to put the kernel at the 0xFFFF800000000000 address in virtual memory, as specified in my linker script: http://pastebin.com/f2f9e0112