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

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

> 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

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

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

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

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

Adapt module loading to support PIE relocations. Generate dynamic GOT if a symbol requires it but no entry exist in the kernel GOT. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier <thgarnie at google.com> --- arch/x86/Makefile | 4 + arch/x86/include/asm/module.h

On 22 May 2013, at 13:23, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Why the private message? If unintentional, please forward this to the list. Ooops, forgot to hit reply-all. Didn't the LLVM lists used to default to reply-to-list behaviour? > So, the JIT is analogous to dlopen, so it should be using general > dynamic and local dynamic models. It is only the

Hi, and thanks in advance for your time. Background - I am working on a package and wish to have a routine's progress reported. The routine can take some time, and I would like to inform the user about the routine's progress. I have scoured the archives but to no avail, so would like to solicit input from this list. I am successfully using cat("\rBootstrap replication ", i,

>> In my opinion having a general linker in the JIT is sub optimal. We >> should not be desiginig lld around an idea there is not even a >> consensus > > I think there is consensus on not wanting duplicate functionality > between LLD and lib/ExecutionEngine. That does not mean that the JIT > needs a general linker, but that whatever functionality is common is >

> On Aug 29, 2020, at 6:53 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> >> Sorry for the delay responding Leonard. I don’t really understand your rationale here. A PLT entry is a completely target specific concept because some targets don’t have PLTs. I don’t think there is any reason that a frontend would abstractly generate this unless they already have a

On Aug 24, 2020, at 6:47 PM, Leonard Chan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Thanks for the responses! I’m going to see if I can summarize the concerns and ideas people have (for my own clarity) and see where we can go on from there. Folks seem to be on board with the idea of introducing some new IR entity that (after linking) *could* be a reference into the PLT, but some

IIUC, the actual requirements for the proposed pltentry(@X) constant is: 1. The returned address MUST have a constant offset at link-time from some other unspecified but defined-in-the-same-binary/DSO symbol Y. Which symbol it is is presumed not to matter because all locally-defined symbols have constant offsets from each-other, anyhow. 2. The address is otherwise insignificant. (Therefore, coming

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() {

----- Original Message ----- > From: "Rui Ueyama" <ruiu at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Rafael Avila de Espindola" <rafael.espindola at gmail.com>, > "llvm-dev" <llvm-dev at lists.llvm.org>, "Andrew Kelley" > <superjoe30 at gmail.com> > Sent: Tuesday, December 13, 2016

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

Someone has reported a problem with predict.coxph that I can't seem to solve. The underlying issue is with model.frame.coxph; the same issue is also found in lm so I'll use that for the example. -------------------------- > test <- data.frame(y = 1:10 + runif(10), x=1:10) > myfun <- function(formula, nd) { fit <- lm(formula, data=nd, model=FALSE)

Dear R-devel, While tracking down some hard-to-reproduce bugs in a package I maintain, I stumbled on a behavior change between R 2.15.0 and the current R-devel (or SVN trunk). In 2.15.0 and earlier, if you passed an 0-length vector of the right mode (e.g., double(0) or integer(0)) as one of the arguments in a .C() call with DUP=TRUE (the default), the C routine would be passed NULL (the C

Hi! Thanks for the feedback. For context, my implementation plan is here: http://pastebin.com/e9JMZNCE First, about unwinding: In architectures like x86-64, where unwinding based on DWARF info, there shouldn't be any problems; since the DWARF info will be emitted correctly. Otherwise, if the unwinding is done by following BP, it should still be possible to have BP de-reference correctly

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