similar to: [LLVMdev] ld crashes with invalid pointer on Ubuntu 11.04 x86 when linking libgcc_s.so

I downloaded the source package for Ubuntu 11.04's ld - it's part of binutils. It's building right now with "-g" on the compile command line, and with --prefix set to install in a subdir of my ~/LLVM directory. I've already tried enabling core dumps: $ ulimit -c unlimited ... but with the release ld that's included with Ubuntu I don't get symbols. Building

On Oct 3, 2011, at 2:33 AM, Don Quixote de la Mancha wrote: > /lib/i386-linux-gnu/libgcc_s.so.1 > bfae3000-bfb07000 rw-p 00000000 00:00 0 [stack] > collect2: ld terminated with signal 6 [Aborted] > make[4]: *** [libgcc_s.so] Error 1 > Signal 6 is SIGABRT so you may want to find out what's calling abort inside ld. An abort usually means that the linker has gotten into

On Thu, Oct 13, 2011 at 10:33 AM, Raja Venkateswaran <rajav at codeaurora.org> wrote: > I think we need a group of maintainers rather than a single maintainer given > the spectrum of ARM targets/ISAs/platforms required to support There have been a plethora of ARM Instruction Set Architecture variants over the years. Which ones do we expect LLVM to support right now, and which as-yet

On Thu, Oct 20, 2011 at 8:46 AM, Bob Wilson <bob.wilson at apple.com> wrote: > This is  http://llvm.org/pr10514 > Unfortunately the fix did not make it into that version of clang. > On Oct 20, 2011, at 7:47 AM, Somorjai, Akos wrote: > The optimization kicks in because 'data' is 16-bytes; but there's no > alignment check… > This seems to be a code generation

Testing on arm-darwin outside of Apple is _complicated_. I had it partially working about two years ago. The general approach is to use rsh/ssh to remotely execute each test on the target, which outside of Apple requires jailbreaking. In the old test system, setting up REMOTE_CLIENT=ssh, REMOTE_PORT, etc. would automatically use ssh to run the tests. In lit, it looks like TestRunner.py has

On Wed, Nov 2, 2011 at 11:05 PM, Don Quixote de la Mancha <quixote at dulcineatech.com> wrote: > A helpful link-time optimization would be to place subroutines that > are used close together in time also close together in the executable > file.  That also goes for data that is in the executable file, whether > initialized (.data segment) or zero-initialized (.bss). > > If

> The ARM Holdings emulator does this; I used it with great success to > profile an Advanced Encryption Standard encryptor a while back. It is indeed a useful piece of kit. We do a lot of our internal regression tests on it, and also run LLVM's regression tests every night on it (as well as PlumHall, EEMBC and SpecInt). Unfortunately it's not exactly software we can give away or

I can't bootstrap llvm-gcc4.2 on Ubuntu 11.04 32-bit. It's not a test failure; instead the configure scripts break in all kinds of mysterious yet spectacular ways. I spent a couple days beating my head against those completely indecipherable shell scripts then gave up for now. Is there a buildbot that runs Ubuntu 11.04? If not may I suggest that one be set up? A minimal Ubuntu

Don Quixote de la Mancha <quixote at dulcineatech.com> writes: > On Sat, Oct 15, 2011 at 7:35 PM, Ivan Krasin <krasin at google.com> wrote: >> I'm not related to the topic starter, but I see at least one huge >> disadvantage of the dependency on link.exe. >> W/o such a dependency it would be possible reliably generate Windows >> executables on Linux or

A helpful link-time optimization would be to place subroutines that are used close together in time also close together in the executable file. That also goes for data that is in the executable file, whether initialized (.data segment) or zero-initialized (.bss). If the unit of linkage of code is the function rather than the compilation module, and the unit of linkage of data is the individual

Well how about as a strawman... taking some options from http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores and http://en.wikipedia.org/wiki/List_of_applications_of_ARM_cores LLVM Supports: ARMv4T -> ARM7TDMI ARMv5TE -> ARM926EJ-S -> XScale ARMv6 -> ARM1136J(F)-S ARMv6ZK -> ARM1176JZ(F)-S ARMv7A -> Cortex-A8 Cortex-A9 ARMv7M -> Cortex-M3

On Fri, Nov 11, 2011 at 5:26 PM, Owen Anderson <resistor at mac.com> wrote: > This is not quite right.  It does have a 12-bit immediate field, but it is decomposed into an 8-bit base immediate and a 4-bit right-rotate value.  Your example of #4000 is encoded as a base value of 0xfa and a rotate of 0xe, which is correct. > >> I don't know what the "it hs" instruction

On Sat, Oct 15, 2011 at 7:35 PM, Ivan Krasin <krasin at google.com> wrote: > I'm not related to the topic starter, but I see at least one huge > disadvantage of the dependency on link.exe. > W/o such a dependency it would be possible reliably generate Windows > executables on Linux or Mac, which has its own benefits (e.g. > distributed compilation) GRUB, the Grand Unified

>> Optimization for size hasn't been tested properly, at least not for >> ARM, and I hit all sorts of trouble (even before getting to DAG) when >> enabling it. > > Bugzilla or it didn't happen. Optimization for size on ARM is more important than most other platforms. It is still very common for embedded ARM cores to have only 64 kb of Flash. A couple friends of

On Thu, Oct 13, 2011 at 11:25 AM, Joe Abbey <jabbey at arxan.com> wrote: > LLVM Supports: > ARMv4T  -> ARM7TDMI > ARMv5TE -> ARM926EJ-S >         -> XScale > ARMv6   -> ARM1136J(F)-S > ARMv6ZK -> ARM1176JZ(F)-S > ARMv7A  -> Cortex-A8 >            Cortex-A9 > ARMv7M  -> Cortex-M3 Does the LLVM code generator generate Thumb code in addition to

On Sun, Oct 16, 2011 at 7:02 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Or just get it from your Linux distro. I didn't realize. That's Just Dandy. > For instance, the > mingw32-binutils package in Debian-based distros will provide a nice > `ld' for cross-compiling to Windows. One Mac OS X there are various i386-mingw32 packages in MacPorts:

Hi James, In that scenario, it would be the responsibility of the client to implement a memory manager for the MCJIT that knows how to import those symbols from the relevant shared library (or resolve them directly to the statically compiled symbols). -Jim On Oct 1, 2012, at 3:09 AM, James Molloy <James.Molloy at arm.com> wrote: > Hi all, > > There are symbols in libgcc (and

On Sat, Oct 15, 2011 at 12:26 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Sat, Oct 15, 2011 at 7:38 AM, Thomson <lilotom at gmail.com> wrote: >> I just found that some samples used link.exe from Visual Studio to generate >> the final image, does LLVM has a replacement for link.exe to generate the >> final binary? I'm not related to the topic

Thanks for the useful information. We notice that the idea of LIPO also can help LLVM LTO if LLVM has FDO/PGO. And regarding Diablo, we'll learn from it and I think we'll get some good ideas from it. In MCLinker, the detail of the instructions and data in bitcode are still kept during linking, so some opportunities to optimize the instruction in bitcode become intuitive. Instruction

Hi all, There are symbols in libgcc (and compiler-rt) that JIT-compiled modules may need. These are currently linked correctly because lli and friends are linked against libgcc_s.so (i.e. shared library version of libgcc, so dlopen/dlsym works). However if a consumer links statically, dlsym won't find all compiler required functions (only the ones that were required by the JIT-compiler