search for: mcmodel

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

...rg/?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...

> 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 Thu, Oct 27, 2016 at 02:42:54PM -0400, John Reagan via llvm-dev > wrote: > > We're at the point in our po...

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 you could let me know it. > > You know, parts of my Uefi firmware (BIOS) have to been loaded to run in high a...

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 I've already posted in the Clang's mailing list, but it seems that the argument is passed to LLVM, so the front-en...

> > 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: text/plain; charset="utf-8" > > I want my GOT, .plt, and other static data to be more than 2GB away > from the code. > Our stack and heap will al...

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

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 address (la...

...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 reasonable requirement. $ gcc -g -O0 -flto codemodel1.c -mcmodel=large -o codemodel1_large_lto_gcc.bin $ objdump -dS codemodel1_large_lto_gcc.bin int main(int argc, const char* argv[]) { 40048b: 55 push %rbp 40048c: 48 89 e5 mov %rsp,%rbp 40048f: 48 83 ec 20 sub $0x20,%rsp 400493:...

> > 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 > > On Thu, Oct 27, 2016 at 05:12:53PM -0400, John Reagan via llvm-dev > wrote: > > I want my GOT, .plt, and other...

...e fact that we don't support it for now seems to indicate that it is not a widely requested feature, especially considering that it is really a trivial option to add. What is the linker you're using? Are you building your own clang? -- Mehdi > > $ gcc -g -O0 -flto codemodel1.c -mcmodel=large -o codemodel1_large_lto_gcc.bin > $ objdump -dS codemodel1_large_lto_gcc.bin > > int main(int argc, const char* argv[]) > { > 40048b: 55 push %rbp > 40048c: 48 89 e5 mov %rsp,%rbp > 40048f: 48 83 ec 20...

> On May 17, 2016, at 11:21 AM, Umesh Kalappa <umesh.kalappa0 at gmail.com> wrote: > > Steven, > > As mehdi stated , the optimisation level is specific to linker and it > enables Inter-Pro opts passes ,please refer function To be very clear: the -O option may trigger *linker* optimizations as well, independently of LTO. -- Mehdi > >

...even with GCC, we could not compile doxygen (with or without -mminimal-toc) without filling up the TOC and hitting the TOC overflow linker error. T fix those types of problems, we recently added two more code models to GCC/binutils, so we're no longer limited to 16-bit TOC offsets. We now how -mcmodel=medium (32-bit TOC offsets) and -mcmodel=large (64-bit TOC offsets), with -mcmodel=medium being the new GCC default (on PPC64). The old TOC code is now called -mcmodel=small. > > > - There is currently no support for generating loops using > > > control-registers for bran...

...seems to indicate that it is not a > widely requested feature, especially considering that it is really a trivial > option to add. > What is the linker you're using? Are you building your own clang? > > -- > Mehdi > > > > > > $ gcc -g -O0 -flto codemodel1.c -mcmodel=large -o > codemodel1_large_lto_gcc.bin > $ objdump -dS codemodel1_large_lto_gcc.bin > > int main(int argc, const char* argv[]) > { > 40048b: 55 push %rbp > 40048c: 48 89 e5 mov %rsp,%rbp > 40048f: 48 83 ec 20...

...rement. The fact that we don't support it for now seems to indicate that it is not a widely requested feature, especially considering that it is really a trivial option to add. What is the linker you're using? Are you building your own clang? -- Mehdi $ gcc -g -O0 -flto codemodel1.c -mcmodel=large -o codemodel1_large_lto_gcc.bin $ objdump -dS codemodel1_large_lto_gcc.bin int main(int argc, const char* argv[]) { 40048b: 55 push %rbp 40048c: 48 89 e5 mov %rsp,%rbp 40048f: 48 83 ec 20 sub $0x20,%rsp 400493:...

...seems to indicate that it is not a widely requested feature, especially considering that it is really a trivial option to add. > What is the linker you're using? Are you building your own clang? > > -- > Mehdi > > > > > > $ gcc -g -O0 -flto codemodel1.c -mcmodel=large -o codemodel1_large_lto_gcc.bin > $ objdump -dS codemodel1_large_lto_gcc.bin > > int main(int argc, const char* argv[]) > { > 40048b: 55 push %rbp > 40048c: 48 89 e5 mov %rsp,%rbp > 40048f: 48 83 ec 20...

...irement. The fact that we don't support it for now seems to indicate that it is not a widely requested feature, especially considering that it is really a trivial option to add. What is the linker you're using? Are you building your own clang? -- Mehdi $ gcc -g -O0 -flto codemodel1.c -mcmodel=large -o codemodel1_large_lto_gcc.bin $ objdump -dS codemodel1_large_lto_gcc.bin int main(int argc, const char* argv[]) { 40048b: 55 push %rbp 40048c: 48 89 e5 mov %rsp,%rbp 40048f: 48 83 ec 20 sub $0x20,%rsp 400493:...

On Sat, 28 Apr 2012 13:55:13 -0500 Hal Finkel <hfinkel at anl.gov> wrote: > On Sat, 28 Apr 2012 13:46:02 -0500 > Hal Finkel <hfinkel at anl.gov> wrote: > > > On Sat, 28 Apr 2012 11:19:13 -0500 > > Peter Bergner <bergner at vnet.ibm.com> wrote: > > > > > On Fri, 2012-04-27 at 20:30 -0500, Hal Finkel wrote: > > > > Thanks! Do you

...ed feature, especially considering that it is really a trivial > > option to add. > > What is the linker you're using? Are you building your own clang? > > > > -- > > Mehdi > > > > > > > > > > > > $ gcc -g -O0 -flto codemodel1.c -mcmodel=large -o > > codemodel1_large_lto_gcc.bin > > $ objdump -dS codemodel1_large_lto_gcc.bin > > > > int main(int argc, const char* argv[]) > > { > > 40048b: 55 push %rbp > > 40048c: 48 89 e5 mov %rsp,%rbp > > 40048f: 48 83 ec 20 sub $0x20,%rsp > >...

On 2020-03-04 10:21, Kees Cook wrote: > On Wed, Mar 04, 2020 at 10:21:36AM +0100, Peter Zijlstra wrote: >> But at what cost; it does unspeakable ugly to the asm. And didn't a >> kernel compiled with the extended PIE range produce a measurably slower >> kernel due to all the ugly? > > Was that true? I thought the final results were a wash and that earlier >