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

> Message: 4 > Date: Thu, 27 Oct 2016 22:04:28 +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: <20161027200428.GA2177 at britannica.bec.de> > Content-Type: text/plain; charset=us-ascii > > On

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

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

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

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

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

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

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

Hi Mehdi, After deeper debug, I found my firmware LTO wrong code issue is related to X64 code model (-mcmodel=large) is always overridden as small (-mcmodel=small) if LTO build. And I don't know how to correctly specific the large code model for my X64 firmware LTO build. Appreciate if you could let me know it. You know, parts of my Uefi firmware (BIOS) have to been loaded to run in 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 05/30/16 01:34 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > We don't use cl::opt in gold, instead we parse the -plugin-opts that > gold passes the plugin (see process_plugin_option). > What about that: $ grep ParseCommandLineOptions tools/gold/gold-plugin.cpp // ParseCommandLineOptions () expects argv[0] to be program name. Lazily cl::

Hi group When I use [TAB] to finish the file name ls shows the file. When I repeat the comman with [UP] ls says there's no such file. Any ideas ? The same thing on Fedora Core 3 and FreeBSD 5.3,4.9 [root@vax ~]# cat /etc/sysconfig/i18n LANG="ru_RU.UTF-8" SUPPORTED="en_US.UTF-8:en_US:en:ru_RU.UTF-8:ru_RU:ru" SYSFONT="latarcyrheb-sun16" [root@vax ~]# mount -t

Hi Mehdi, GCC LTO seems support large code model in my side as below, if the code model is linker specific, does the GCC LTO use a special linker which is different from the one in GNU Binutils? I'm a bit surprised if both OS X ld64 and gold plugin do not support large code model in LTO. Since modern system widely use the 64bit, the code need to run in high address (larger than 2 GB) is a

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

We don't use cl::opt in gold, instead we parse the -plugin-opts that gold passes the plugin (see process_plugin_option). Cheers, Rafael On 30 May 2016 at 02:13, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On May 29, 2016, at 5:44 PM, Shi, Steven <steven.shi at intel.com> wrote: > > (And I doubt the GNU linker supports LTO with LLVM). > [Steven]: I’ve pushed

(And I doubt the GNU linker supports LTO with LLVM). [Steven]: I’ve pushed GNU Binutils ld to support LLVM gold plugin, see detail in this bug https://sourceware.org/bugzilla/show_bug.cgi?id=20070. The new GNU ld linker works well with LLVM/Clang LTO when build IA32 code in my side. And from the ld owner input in the bug comments, the current X64 LLVM LTO issue is in llvm LTO plugin. The fact

Hi, > On May 29, 2016, at 7:36 AM, Shi, Steven <steven.shi at intel.com> wrote: > > Hi Mehdi, > After deeper debug, I found my firmware LTO wrong code issue is related to X64 code model (-mcmodel=large) is always overridden as small (-mcmodel=small) if LTO build. And I don't know how to correctly specific the large code model for my X64 firmware LTO build. Appreciate if

Hello, I am using odesolve to simulate a group of people moving through time and transmitting infections to one another. In Matlab, there is a NonNegative option which tells the Matlab solver to keep the vector elements of the ODE solution non-negative at all times. What is the right way to do this in R? Thanks, Jeremy P.S., Below is a simplified version of the code I use to try to do this,

Hi Mehdi, Should I apply your attached patch on my llvm3.8 source firstly? Or should I use the latest llvm SVN trunk instead? Steven Shi Intel\SSG\STO\UEFI Firmware Tel: +86 021-61166522 iNet: 821-6522 From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Monday, May 30, 2016 2:13 PM To: Shi, Steven <steven.shi at intel.com> Cc: Umesh Kalappa <umesh.kalappa0 at