search for: melf_i386

...t tests, but I hope that fixing the first test will allow me to continue). I see syntax errors from the C compiler and core dumps from llc. Is any of this supposed to happen? This is still on my amd64 machine. However, the build process is using the right incantation to compile (gcc-4.2 -m32 -Wl,-melf_i386). The llvm-gcc toolchain installed is the precompiled 2.2 Red Hat package for Linux. See below for the error messages, and further below for the source lines mentioned in the messages. Should I worry about these messages? I haven't tested actually using LLVM yet, and I may be barking up the w...

16396:055d98aa2dd0 almost works but not quite. LDFLAGS_DIRECT means we end up with: gld -melf_i386 -nostdlib -N -Ttext 0x100000 -o hvmloader.tmp hvmloader.o mp_tables.o util.o smbios.o 32bitbios_support.o acpi/acpi.a Specifying a linker script and asking for -nostdlib is obviously contradictory. Removing $(LDFLAGS_DIRECT) fixes the problem. regards john _______________________________________...

...-o bug-64-ld bug-64.o $ x86_64-elf-objdump -M i386 -d bug-64-ld | grep -A1 -e '<_start>:' 0000000000400080 <_start>: 400080: e8 0b 00 00 00 call 400090 <foo> Linking the 32-bit object file works correctly with both GNU ld and ld.lld. $ ./llvm-build/bin/ld.lld -melf_i386 -o bug-lld bug.o $ x86_64-elf-objdump -d bug-lld | grep -A1 -e '<_start>:' 00011000 <_start>: 11000: e8 0b 00 00 00 call 11010 <foo> $ x86_64-elf-ld -melf_i386 -o bug-ld bug.o $ x86_64-elf-objdump -d bug-ld | grep -A1 -e '<_start>:' 08048060 <_...

...do this with llvm? > Simple, use ld on the .o files, as you would with gcc. An example with clang: $ clang -nostartfiles -c x.c -o x.o $ ld -o x x.o --oformat binary Or to get a 32-bit one: $ /llvm-git/obj/Release/bin/clang -nostartfiles -c x.c -o x.o -m32 $ ld -o x1 x.o --oformat binary -melf_i386 This one is indeed 5 bytes long. Best regards, --Edwin

Hey, The following code creates a raw binary (no ELF or PE.. just raw): gcc -nostartfiles -c -o hello.o hello.c ld -o hello1 hello.o --oformat binary You can try the following code out with it: void _start() { while(1); } The resulting raw binary is 5 bytes. Now how do you do this in clang/llvm? Apparently llvm-ld doesn't have a "--oformat binary" option. Anybody know how to

...Thank you, Ven Török Edwin wrote: > > > An example with clang: > $ clang -nostartfiles -c x.c -o x.o > $ ld -o x x.o --oformat binary > > Or to get a 32-bit one: > $ /llvm-git/obj/Release/bin/clang -nostartfiles -c x.c -o x.o -m32 > $ ld -o x1 x.o --oformat binary -melf_i386 > > This one is indeed 5 bytes long. > > Best regards, > --Edwin > > -- View this message in context: http://old.nabble.com/Compiling-a-raw-binary-with-llvm-clang-tp26834182p26834869.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

...he behaviour that I encountered. If I'm correct, the bugs are just in the dejagnu-based test machinery, not in LLVM itself. There seem to be two issues: Issue 1 is that the CC, CFLAGS, CXX, and CXXFLAGS settings are not reflected in the site.exp file. I had CC=gcc-4.2 CFLAGS="-m32 -Wl,-melf_i386" CXX=g++-4.2 CXXFLAGS=$CFLAGS ARCH=i686-pc-linux-gnu ./configure --prefix=$HOME --target=$ARCH --host=$ARCH --build=$ARCH but site.exp still has set gccpath "gcc" set gxxpath "g++" and no mention of -m32 or -Wl,elf_i386 (these options are required to force a 64-bit...

Sorry for not explaining well. After compiling with g++-cross g++-cross -c a.c I do link using this command /gold_binutils/build/gold/ld-new -plugin ~/Desktop/Sanjeev/LLVM/llvm-2.7/Release/lib/libLLVMgold.so --eh-frame-hdr -melf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0/crtbegin.o -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0 -L/usr/local/lib -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc -lpthread -lrt --as-needed -lgcc_s --no-as-needed /usr/local/lib...

> ~/Desktop/Sanjeev/LLVM/llvm-2.7/Release/lib/libLLVMgold.so --eh-frame-hdr > -melf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o Ok, this way you're generating code for x86 > /usr/lib/crti.o > /usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0/crtbegin.o > -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0  -L/usr/local/lib -lgcc > --as-needed -lgcc_s --no-as-needed -lc -...

> Yes, I'm following this page only and did whatever is mentioned there. It doesn't seem so. E.g. it contains the following line: "The linker takes a -plugin option that points to the path of the plugin .so file." and "Replace that with ld-new -plugin /path/to/libLLVMgold.so to test it out." At least you are not telling ld-new to use any plugin. Thus ld-new does not

Yes, I'm following this page only and did whatever is mentioned there. On Mon, Jul 12, 2010 at 6:57 PM, Sanjeev chugh <sanjuchugh at gmail.com> wrote: > Did you mean ld-new ? > > ld-new -v > GNU gold (GNU Binutils 2.20.51.20100707) 1.9 > > ld-new --help > ./ld-new: supported targets: elf32-i386 elf32-i386-freebsd elf64-x86-64 > elf64-x86-64-freebsd elf64-sparc

Hi all again, llvm is failing the 2006-11-30-NoCompileUnit and 2006-11-30-Pubnames tests on me. -m32 and --disable-multilib didn't change the outcome. Did I get the command wrong? I tried jo at kurier:~/Delta/llvm/test$ CFLAGS=--multilib make check See below for a transcript of the failed check. What next? Regards, Jo -- snip -- jo at kurier:~/Delta/llvm/test$ make check llvm[0]:

...e one test and propose it as a model for other tests. Thanks for working on this! -Chris > > There seem to be two issues: > > > Issue 1 is that the CC, CFLAGS, CXX, and CXXFLAGS settings are not > reflected in the site.exp file. I had > CC=gcc-4.2 > CFLAGS="-m32 -Wl,-melf_i386" > CXX=g++-4.2 > CXXFLAGS=$CFLAGS > ARCH=i686-pc-linux-gnu > ./configure --prefix=$HOME --target=$ARCH --host=$ARCH --build=$ARCH > but site.exp still has > set gccpath "gcc" > set gxxpath "g++" > and no mention of -m32 or -Wl,elf_i386 (these optio...

# HG changeset patch # User Olaf Hering <olaf@aepfle.de> # Date 1332851995 -7200 # Node ID 9c6337771520b390ed624fa6b6b2f2edc8042701 # Parent d9e6e8632bb6b9a2144e7e148bc7ea53ea4933fd tools/configure: add options to pass EXTRA_CLFAGS Currently qemu-xen will be compiled with CFLAGS only if CFLAGS was already in the environment during make invocation. If CFLAGS is in environment then make will

...sed -n '/[0-9]/{s,00*,0,g;p}' |\ while read idx name sz rest; do \ case "$name" in \ .data|.data.*|.rodata|.rodata.*|.bss|.bss.*) \ test $sz != 0 || continue; \ echo "Error: non-empty $name: 0x$sz" >&2; \ exit $(expr $idx + 1);; \ esac; \ done ld -melf_i386 -N -Ttext 0 -o reloc.lnk reloc.o objcopy -O binary reloc.lnk reloc.bin (od -v -t x reloc.bin | tr -s ' ' | awk 'NR > 1 {print s} {s=$0}' | \ sed 's/ /,0x/g' | sed 's/,0x$//' | sed 's/^[0-9]*,/ .long /') >reloc.S make[7]: Leaving directory '/??PKGBUI...

...--with-float=softfp --disable-bootstrap --disable-libmudflap --disable-libssp Thanks & Regards Sanjeev On Mon, Jul 12, 2010 at 7:55 PM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > > ~/Desktop/Sanjeev/LLVM/llvm-2.7/Release/lib/libLLVMgold.so --eh-frame-hdr > > -melf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o > Ok, this way you're generating code for x86 > > > /usr/lib/crti.o > > /usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0/crtbegin.o > > -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0 -L/usr/local/lib -lgcc > > --as-needed...