search for: notypes

Hello. That's what I've got from ld: /usr/lib/libxenguest.a(xg_private.o): In function `unlock_pages': (.text+0x490): multiple definition of `unlock_pages' /usr/lib/libxenctrl.a(xc_private.o):(.text+0x6a0): first defined here /usr/lib/libxenguest.a(xg_private.o): In function `lock_pages': (.text+0x4d0): multiple definition of `lock_pages'

On Fri, Oct 19, 2012 at 2:55 AM, r4start <r4start at gmail.com> wrote: > Hi all. > > While compiling next code > @A = weak unnamed_addr constant { i32, i32, i32 } { i32 0, i32 0, i32 0 }, > section ".data" > was discovered that llc ignores weak linkage if we emit it in COFF object. > Attached patch solves this problem, please review. > > I found some

Great, thanks for your help. I'll take a crack at it and contact Renato if I have questions. -Greg On Wed, Oct 10, 2012 at 1:05 PM, Jim Grosbach <grosbach at apple.com> wrote: > Cool; glad to help. > > When I added the data region bits, I tried to keep the ARM-style annotations in mind a bit, so hopefully things will fit together without too much trouble. > > -Jim >

Hi all. While compiling next code @A = weak unnamed_addr constant { i32, i32, i32 } { i32 0, i32 0, i32 0 }, section ".data" was discovered that llc ignores weak linkage if we emit it in COFF object. Attached patch solves this problem, please review. I found some similar tests in test/Objects/Inputs. Should I do something like trivial.ll checking or there is a better way to check

Getting closer... When emitting symbols, how do I set the symbol's value to the address of the current instruction? Do I need to emit a label in the current section and another that uses the former to point to the latter? If possible, a code sample would be very helpful. And probably questions for Tim, are these "section-relative" mapping symbols, as defined in 4.6.5.1 of the

On 20/10/12 03:15, Michael Spencer wrote: > On Fri, Oct 19, 2012 at 2:55 AM, r4start <r4start at gmail.com> wrote: >> Hi all. >> >> While compiling next code >> @A = weak unnamed_addr constant { i32, i32, i32 } { i32 0, i32 0, i32 0 }, >> section ".data" >> was discovered that llc ignores weak linkage if we emit it in COFF object. >>

CC llvm-dev ---------- Forwarded message ---------- Hello Duncan The size of ARM binaries created by clang has increased after r236642. Would you be able to find some time to look at my findings and share your thoughts about the problem, please? r236642 prevents emitting of temp label names into object files to save memory. This is fine, the label names do not appear in the resulting binaries.

Hi David, On Thu, Jun 7, 2012 at 10:17 AM, Fan Dawei <fandawei.s at gmail.com> wrote: > Could you please tell me more about $a, $t and $d symbols? How these symbols > are used to define different regions? Where I can find this symbols in ELF > object file? At the start of each range of ARM code, an assembler or compiler should produce a "$a" symbol with that address, and

Dear R community, I am a newbie to R and I am using lme() to analyzed a two way repeated measures ANCOVA on some data I have gathered. In producing some graphs based on the fixed effects I noticed that I get vary different results depending on how I order my levels in my factor statement (see code below). Now, I have read that different models treat data from the factor class

Hi Tim, Thanks a lot for your help! I'm very grateful. libc.so is a prelinked library, I'll build a non-prelinked one and have another try. I'm now at the start of a binary translation project. I want to convert ARM binary code [*] to llvm ir, which is then translated to binary for our mips like architecture. That's why I'm looking for a decoder for ARM binary. The

Cool; glad to help. When I added the data region bits, I tried to keep the ARM-style annotations in mind a bit, so hopefully things will fit together without too much trouble. -Jim On Oct 10, 2012, at 12:05 PM, Renato Golin <rengolin at systemcall.org> wrote: > Thanks Jim! > > I have updated the bug with your comments, I think it's a good start. > > Greg, let me know

Hi Dean, Wondering if you've seen anything like this: /usr/local/google/home/blaikie/dev/llvm/build/clang/debug/split/notypes/nostandalone/projects/compiler-rt/lib/xray/tests/unit && /usr/local/google/home/blaikie/dev/llvm/build/clang/debug/split/notypes/nostandalone/./bin/clang fdr_logging_test.cc.x86_64.o xray_unit_test_main.cc.x86_64.o gtest-all.cc.x86_64.o -o /usr/local/google/home/blaikie/dev/llvm/build/clang...

Hi Jim, Thanks for reply. I'm sorry I didn't make myself clear enough. The MCInst created by MCDisassembler depends on the instructions defined in td files. These instructions do not have a one to one mapping to ARM instructions. There are usually one or more instructions defined in the td file correspond to one actual ARM instruction. Thanks, David On Thu, Jun 7, 2012 at 1:27 PM, Jim

Hi Tim, Thanks a lot for the reply. I tested libc.so which is a shared library. llvm-objdump also report some disassemble errors. Could you please tell me more about $a, $t and $d symbols? How these symbols are used to define different regions? Where I can find this symbols in ELF object file? Thanks, David I'm now try to find a decoder of ARM instructions in oder On Thu, Jun 7, 2012

On Jun 7, 2012, at 7:53 AM, Fan Dawei <fandawei.s at gmail.com> wrote: > Hi Tim, > > Thanks a lot for your help! I'm very grateful. > > libc.so is a prelinked library, I'll build a non-prelinked one and have another try. > > I'm now at the start of a binary translation project. I want to convert ARM binary code [*] to llvm ir, which is then translated to

...w, so > removing it seems like a not great idea at the moment. > > > That said, I tried putting compiler-rt in runtimes instead of projects and > I got a bunch of cmake errors starting with: > > CMake Error at > /usr/local/google/home/blaikie/dev/llvm/build/clang/debug/split/notypes/nostandalone/lib/cmake/llvm/AddLLVM.cmake:1174 > (add_dependencies): > The dependency target "GotsanRuntimeCheck" of target "check-runtimes" > does > not exist. > Call Stack (most recent call first): > CMakeLists.txt:110 (add_lit_target) > > Any ide...

Hello -- I desperately want to start using Ogg compression on music I release on the internet, but I am encountering a fair amount of artifacts. I noticed some in beta4 and was hoping they would disappear with RC1. However, I've been playing with RC2 and I've still been banging my head into a number of problems. A majority of the music I make has long drones with a fair amount of spectral

That depends on how you define "one ARM instruction." It's not a clear cut thing. For example, is "add r1, r2, r3" the same ARM instruction as "add r1, r2, #4"? What is a distinct instruction and what's a variant encoding of the same instruction is often entirely a matter of convenience. -Jim On Jun 8, 2012, at 6:40 AM, Fan Dawei <fandawei.s at

On 16 October 2012 03:16, Greg Fitzgerald <garious at gmail.com> wrote: > Lastly, from MCELFStreamer, how do I determine if we generating an ARM or > Thumb ELF? That was the only part I didn't know how to get. Jim should know. > I can catch Thumb from the EmitThumbFunc, but that seems a > little odd. Ignore EmitThumbFunc, it has nothing to do with your change. > $

Compiling llvm on a linux/amd64 box produces: home/rafael/dev/llvm/build/Debug/lib/LLVMX86.o: In function `_X86CompilationCallback': (.text+0x316fe): undefined reference to `_X86CompilationCallback2' /home/rafael/dev/llvm/build/Debug/lib/LLVMX86.o: In function `llvm::X86JITInfo::getLazyResolverFunction(void* (*)(void*))': /home/rafael/dev/llvm/cvs/lib/Target/X86/X86JITInfo.cpp:219: