similar to: [LLVMdev] Recommended cpu emulator for OS X

What kinds of errors are you getting? On Thu, Oct 7, 2010 at 9:36 AM, Pradeep Ramachandran <pramach2 at uiuc.edu> wrote: > Hi, > I recently downloaded and installed the libcpu package (from http://libcpu.org > ) that uses llvm as the backend on my linux machine. I have a piece of > Motorola 88100 code (essentially the output of the 176.gcc benchmark > from SPEC CPU 2000) that

Hi, I recently downloaded and installed the libcpu package (from http://libcpu.org ) that uses llvm as the backend on my linux machine. I have a piece of Motorola 88100 code (essentially the output of the 176.gcc benchmark from SPEC CPU 2000) that I am trying to run using this emulator, but I am running into errors when trying to run it. Has anyone been able to successfully use the m88k

I think so. It also fails the same way on LLVM trunk from last week. The full backtrace is below. It appears that frame #3 is a compilation of __l_personality() and frame #14 is a compilation of f(). The compilation of __l_personality appears to have been triggered by the need to output DWARF information for f(). -- James #0 0x00007ffff6ed84b5 in *__GI_raise (sig=<value optimised out>) at

Interesting. Was this the reason you were getting the recursive compilation error in JIT::runJITOnFunctionUnlocked(...) (isAlreadyCodeGenerating)? Do you have the time to try your test with 2.7? Garrison On Jan 22, 2010, at 17:37, James Williams wrote: > I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed

I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed before any unwind happens. -- James 2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > No, there is no magic. :-) > > To me though, the tools are magic, because I have no clue what they are > doing without looking at them and using them. >

No problem I'll drop this from our discussion as it really is only germane to my learning path and imagination. :-) I do at this time still have this concern of allowing a user (developer) the right to turn this "cross module linkage" off, but I'm still in the process of understanding your previous comments on this. Thanks again for the help and time by the way. Garrison PS:

On Sun, Jan 10, 2010 at 12:38 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Won't passing llvm::Function* around vs strings (function names), also work, at code generation time, > without the need for a module A dec to module B impl. mapping? > > Garrison Nope. You cannot place a call instruction into one module whose callee is a Function from another module. You

Hi James, Just wanted to update you. As you implied the problem here is that the personality function has to be jitted before the code that contains the corresponding llvm.eh.selector intrinsic instruction is jitted. I verified this by creating a generated version of the personality function which unless I jitted first, gave me the same error when running the code. Since you are using tools

On Jan 13, 2010, at 12:46, Dustin Laurence wrote: > On 01/13/2010 04:08 AM, Garrison Venn wrote: > >> If it helps, to see what is involved, outside of a pure IR context, >> see the example code, and doc at: >> >> http://wiki.llvm.org/HowTo:_Build_JIT_based_Exception_mechanism#Source_Code:_exceptionDemo.cpp > > It does, although in the "let me show you

Hi Eli So I found this in Attributes.h: const Attributes UWTable = 1<<30; ///< Function must be in a unwind ///table What does this mean? In particular what does it mean not to add this as a function attribute to a function? I'm obviously going down the wrong road in my interpretation, as I

Several people on this list have reported issues with the linker regarding a named StructType instance with the same name in two different modules being resolved into two StructTypes with different names due to StructType:: setName(…) collision behavior. Looking at BitcodeReader::ParseTypeTableBody(…), I don't see use of LLVMContextImpl::NamedStructTypes or of Module::getTypeByName(…). Nor do

Hi Jeffrey, On Feb 26, 2010, at 16:02, Jeffrey Yasskin wrote: > [sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing] Sorry just saw some preexisting code was not in 80 columns. > > On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hi

If the powers at be want this, I could easily transform the source to the LLVM coding standards, and add the necessary portable UNIX support--someone else would have to add non-UNIX support although the System library probably helps with this. However I'm guessing the LLVM release flux of the exception system, along with a lack of universal platform, dwarf JIT support might be a hinderance in

No, there is no magic. :-) To me though, the tools are magic, because I have no clue what they are doing without looking at them and using them. As their function is not germane to my current endeavors, I hope to learn about them from this list, and most likely from your postings. I know it is a common approach, but to me I think bitcode generation to JIT runtime is a a cool feature of LLVM.

Sorry to keep this thread alive, but I'm learning so ... There is more. The doc for GlobalValue::LinkageTypes or the C API LLVMLinkage is not as clear as the lang ref manual. See: http://llvm.org/docs/LangRef.html#linkage. I'm pointing this out because something like LinkerPrivateLinkage (LLVMLinkerPrivateLinkage), or another one, might be more appropriate to your throw away use case (if

On 04/04/2012 07:08 AM, Charles Davis wrote: > Hi, > > Here's one of my proposals for GSoC 2012. What do you think? > > Chip > > Project Title: Table-Driven Decompilation > > Abstract: > Over the years, the LLVM family has grown to include nearly every type of build tool in existence. One of the few missing is a decompiler. LLVM's TableGen tool could

[sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing] On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com>wrote: > Hi Olivier, > > On Feb 25, 2010, at 14:10, Olivier Meurant wrote: > > Hi Garrison, > > I finally come back from holidays and take

Hi! If a pass is required then it makes sense to getAnalysis<DwarfWriter>(). getAnalysisIfAvailable<>() is used for cases where a pass want to take advantage of (or fix up) info only *if* it is available. If you prepare a patch to fix getAnalysisifAvailable<>() uses (e.g. DwarfWriter requests you mention below) then I'll apply it. - Devang On Tue, Dec 8, 2009 at 11:11

On Sat, Jul 23, 2011 at 2:36 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hi Bill, > > Thanks for working on this. > > Is there a reference for the function attribute uwtable, or is it to be defined as > part of this effort? It already exists; there's some limited documentation in the LLVM source, but Rafael apparently forgot to add it to LangRef... -Eli

Kenneth Uildriks wrote: > On Sun, Jan 10, 2010 at 12:38 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > > Won't passing llvm::Function* around vs strings (function names), also work, at code generation time, > > without the need for a module A dec to module B impl. mapping? > > > > Garrison > > Nope. You cannot place a call instruction into one