search for: elf32_x86_64

I have installed dom0 Wheezy 64 bit on Dell PowerEdge T310 with kernel from package and xen-unstable. System is in Uefi mode and booted with grub-efi-amd64. Booting without xen efibootmgr works, while with xen not, efivars kernel module is loaded but show this message: efibootmgr Fatal: Couldn''t open either sysfs or procfs directories for accessing EFI variables. Try ''modprobe

.../wiki/Xen_EFI#Compiling_Xen_as_EFI Which sugests binutils doesn't support PE (EFI), which looks to be the case with the stock version on CentOS 7, note missing i386pe from the list of supported emulations: # ld -V GNU ld version 2.25.1-32.base.el7_4.2 Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 i386linux elf_l1om elf_k1om I downloaded binutils 2.30 from http://ftp.gnu.org/gnu/binutils/ and built it with: yum -y groupinstall "Development Tools" tar xzf binutils-2.30.tar.gz cd binutils-2.30 ./configure --enable-targets=x86_64-pep make make install Now I hav...

This patch is still not creating elf32_x86_64 objects. No idea why. :( It does however, fix elf_x86_64 (-m64) code generation on x32 hosts which is nice. :) --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6...

...ies > > > > > that are expected to work on a given arch. > > > > > > > > > I should have made clear this is very much a WIP. I expect to have make > > > > an effort to port compiler-rt, but first I need to be able to generate > > > > elf32_x86_64 objects with Clang. I confess, my method of porting code > > > > to x32 so far has consisted of trying to build existing code and > > > > modifying what breaks, or disabling features where inapplicable. I > > > > haven't studied the code well enough to unde...

On Thu, 2013-08-22 at 15:22 +0100, Steven Newbury wrote: > This patch is still not creating elf32_x86_64 objects. No idea > why. :( It does however, fix elf_x86_64 (-m64) code generation on x32 > hosts which is nice. :) I know why. I had assumed Michael Liao (the original patch author) had submitted all the _LLVM_ x32 support as separate patches, and it was just the tests/Clang/compiler-rt su...

...and we don't plan > to do this anytime soon. I think it makes sense to build only the libraries > that are expected to work on a given arch. > I should have made clear this is very much a WIP. I expect to have make an effort to port compiler-rt, but first I need to be able to generate elf32_x86_64 objects with Clang. I confess, my method of porting code to x32 so far has consisted of trying to build existing code and modifying what breaks, or disabling features where inapplicable. I haven't studied the code well enough to understand and predict where I'm going to have make modifica...

...it makes sense to build only the > > libraries > > > that are expected to work on a given arch. > > > > > I should have made clear this is very much a WIP. I expect to have make > > an effort to port compiler-rt, but first I need to be able to generate > > elf32_x86_64 objects with Clang. I confess, my method of porting code > > to x32 so far has consisted of trying to build existing code and > > modifying what breaks, or disabling features where inapplicable. I > > haven't studied the code well enough to understand and predict where I'...

...do this anytime soon. I think it makes sense to build only the > libraries > > that are expected to work on a given arch. > > > I should have made clear this is very much a WIP. I expect to have make > an effort to port compiler-rt, but first I need to be able to generate > elf32_x86_64 objects with Clang. I confess, my method of porting code > to x32 so far has consisted of trying to build existing code and > modifying what breaks, or disabling features where inapplicable. I > haven't studied the code well enough to understand and predict where I'm > going t...

...the > > > libraries > > > > that are expected to work on a given arch. > > > > > > > I should have made clear this is very much a WIP. I expect to have make > > > an effort to port compiler-rt, but first I need to be able to generate > > > elf32_x86_64 objects with Clang. I confess, my method of porting code > > > to x32 so far has consisted of trying to build existing code and > > > modifying what breaks, or disabling features where inapplicable. I > > > haven't studied the code well enough to understand and pred...

Hi James, renato, So how do I download the missing ARM libraries on Ubuntu14.04? I cannot find any available libraries. Best, Liyang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160425/04dfc553/attachment.html>

...w patches for various packages to push upstream, but right now, the biggest blocker is the lack of support for building with/codegen targeting x32 in llvm/clang. Since the x32 patches were sent last year, I see support code has landed in LLVM, and basic handling of 32-bit pointers in Clang, but no elf32_x86_64 codegen or support for the -mx32 switch. I've been trying to get x32 ABI support working in Clang and compiler-rt, I based off the previous clang patch, bringing it up to date with the changes in trunk, and hacked together handling of x32 "ARCH" support for compiler-rt. (there must b...

...CmdArgs.push_back("elf64_s390"); - else - CmdArgs.push_back("elf_x86_64"); + else if (ToolChain.getArch() == llvm::Triple::x86_64) + CmdArgs.push_back(ToolChain.getTriple().getEnvironment() == + llvm::Triple::GNUX32 + ? "elf32_x86_64" : "elf_x86_64"); + else + llvm_unreachable("unknown arch"); if (Args.hasArg(options::OPT_static)) { if (ToolChain.getArch() == llvm::Triple::arm --- ./tools/clang/lib/Driver/ToolChains.cpp.orig 2013-08-18 14:18:42.527568969 +0000 +++ ./tools/clang/lib/Driver...

...n /home/hum/Documents/Projects/llvm_clang/build/Debug+Asserts/bin/../lib/LLVMgold.so /tmp/hello-T8xLAt.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed crtend.o crtn.o /usr/bin/ld: unrecognised emulation mode: armelf_linux_eabi Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 i386linux elf_l1om elf_k1om clang: error: linker command failed with exit code 1 (use -v to see invocation) 6. The problem occurred when clang starts to link with ld. Clang tried to use the ld in a wrong place - "/usr/bin/ld". So I tried it myself like below. /home/hum/Documen...

On Sat, Jun 16, 2012 at 08:20:23PM +0900, Journeyer J. Joh wrote: > If the cross compiling is supported, is there any documentation on how to > do it? The short version is: assuming you have a cross-binutils installation using e.g. x86_64--netbsd-as and x86_64--netbsd-ld, you add a symlink called x86_64--netbsd-clang to clang and just call that with an appropiate --sysroot to make it find

Hello list, I wonder if llvm/Clang can compile C or C++ for ARM from on x86. http://comments.gmane.org/gmane.comp.compilers.clang.devel/8896 The talk above answered 'NO' to my question, which means Clang is not yet able to cross compile for ARM on X86. Is the answer still correct for my question? I saw somewhere that Clang supports ARM on Darwin only. Then is the cross compiling

Hello > ./clang -v -emit-llvm -ccc-host-triple arm-none-linux-gnueabi > -I/home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/include > -L/home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/bin hello.c You forgot about sysroot here. > /home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/bin/ld: > unrecognised emulation mode: armelf_linux_eabi >

...arm_toolchain/arm-2010.09/lib/gcc/arm-none-linux-gnueabi/4.5.1/armv4t/crtend.o needs to be used!!!) /home/hum/Documents/Projects/arm_toolchain/arm-2010.09/arm-none-linux-gnueabi/libc/usr/lib/crtn.o /usr/bin/ld: unrecognised emulation mode: armelf_linux_eabi Supported emulations: elf_i386 i386linux elf32_x86_64 elf_x86_64 elf_l1om elf_k1om clang: error: linker command failed with exit code 1 (use -v to see invocation) Problem #1 : wrong linker! ld in cross toolchain is needed! Problem #2 : All libraries have to be of the cross toolchain! Problem #3 : All libraries have to be of the cross toolchain! (/ho...

Hi Steven, This looks interesting and raises a number of questions :) 1) Does applying this patch actually bring working sanitizers to x32 platform? That is, after you build the clang, does "clang -fsanitize=whatever foo.c" compile/link/run with expected results? I doubt that, as there is some platform-specific code in all the sanitizers, and many of them heavily depend on the address

...b. +# +KLIBCARCHREQFLAGS = -mx32 +KLIBCOPTFLAGS += -Os -fomit-frame-pointer -mno-sse \ + -falign-functions=1 -falign-jumps=1 -falign-loops=1 +ifeq ($(DEBUG),y) +KLIBCOPTFLAGS += -g +else +KLIBCOPTFLAGS += -fno-asynchronous-unwind-tables +endif +KLIBCBITSIZE = 32 +KLIBCLDFLAGS = -m elf32_x86_64 + +# Extra linkflags when building the shared version of the library +# This address needs to be reachable using normal inter-module +# calls, and work on the memory models for this architecture +# 2 MB - normal binaries start at 4 MB +# +# Recent binutils use max-page-size=0x200000 by default, whi...

X32 support patch for compiler-rt. Applies against current trunk. --- projects/compiler-rt/make/platform/clang_linux.mk~ 2013-08-21 06:27:38.000000000 +0000 +++ projects/compiler-rt/make/platform/clang_linux.mk 2013-08-21 11:16:55.891621025 +0000 @@ -41,7 +41,18 @@ SupportedArches += x86_64 endif else - SupportedArches := x86_64 + # x86-64 arch has two ABIs 64 bit x86-64 and 32 bit