Hi
When compiling UnixLocalInferiorProcess.cpp, I get these errors:
This file (UnixLocalInferiorProcess.cpp) is due for porting and placement in lib/System but I haven't gotten there yet. If you come up with something that works on MINGW, please let me know.
Thanks,
Reid.
Henrik Bach wrote:
This file (UnixLocalInferiorProcess.cpp) is due for porting and placement in
lib/System but I haven't gotten there yet. If you come up with something that
works on MINGW, please let me know.
As you might guess by the name, this file is essentially entirely unix
specific. The debugger is designed so that multiple backends can be
plugged into it for different purposes: I don't think that "porting" this
to make it work on win32 would be sufficient in any case. Can't you just
disable the build of this file on non-unix systems?
-Chris
Henrik Bach wrote:
> Hi
>
> When compiling UnixLocalInferiorProcess.cpp, I get these errors:
> -----------------------
> C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:41:22:
> sys/wait.h: No such file or directory
> C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:
> In
> member function `void <unnamed>::IP::startChild(llvm::Module*, const
> std::vector<std::string, std::allocator<std::string> >&, const char*
> const*)
> ':
> C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:255:
> error: `
> pipe' undeclared (first use this function)
> C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:255:
> error: (Each
> undeclared identifier is reported only once for each function it appears
> in.)
> C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:264:
> error: `
> fork' undeclared (first use this function)
> C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:
> In
> member function `void <unnamed>::IP::killChild() const':
> C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:428:
> error: `
> WNOHANG' undeclared (first use this function)
> C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:428:
> error: `
> waitpid' undeclared (first use this function)
> C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:437:
> error: `
> usleep' undeclared (first use this function)
> C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:452:
> error: `
> WIFEXITED' undeclared (first use this function)
> C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:453:
> error: `
> WEXITSTATUS' undeclared (first use this function)
> C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:454:
> error: `
> WIFSIGNALED' undeclared (first use this function)
> C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:455:
> error: `
> WTERMSIG' undeclared (first use this function)
> C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:460:
> error: `
> SIGKILL' undeclared (first use this function)
> C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:460:
> error: `
> kill' undeclared (first use this function)
> -----------------------
>
> It seems to be unix platform specific. However, I'm compiling this on
> MinGW. Shouldn't this be moved to lib/System/platform for every platform?
>
> Any suggestions?
>
> =============================================================
> Henrik Bach
> Open Source Developer
>
> e-mail: henrik_bach_llvm at hotmail.com
> =============================================================
> Got Freedom?
> Software Freedom Day 2004 - 28th of August
> http://www.softwarefreedomday.org/
> =============================================================
>
> _________________________________________________________________
> Opret en gratis Hotmail-konto http://www.hotmail.com med udsigt til 250
> MB lagerkapacitet
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
-Chris
Hi,
I am interested in the JIT compiler of llvm, namely, lli. I want to know
more about it, but I found little documentation about it. There are a few
paragraphs about JIT in the CGO paper, a list of options dumped from "lli
--help-hidden", and a short webpage of lli in the website. But many issues
are not clearly described. For example,
1. When JIT is available (-force-interpreter=false), under what condition
the JIT compilation will be applied? (Is it applied to any code that is
executed, or just to hot code like Dynamo?)
2. What algorithms are used to identify hot loop regions and hot paths for
runtime reoptimization?
3. How to relate identified executing native code (of hot loops and
regions) back to original LLVM bytecode?
4. What runtime optimizations are applied in the current version?
Would it be possible to provide a more detailed document? If not
convenient, please give us a brief description of files which are in
charge of these functions. I appreciate your effort and time. Thanks.
Shukang Zhou
I am interested in the JIT compiler of llvm, namely, lli. I want to know
more about it, but I found little documentation about it. There are a few
paragraphs about JIT in the CGO paper, a list of options dumped from "lli
--help-hidden", and a short webpage of lli in the website. But many issues
are not clearly described. For example,
Unfortunately there isn't just that describes it. 
1. When JIT is available (-force-interpreter=false), under what condition
the JIT compilation will be applied? (Is it applied to any code that is
executed, or just to hot code like Dynamo?)
When the JIT is available, it is always used. JIT availability depends on
whether we have a code generator for the current target or not: currently
we support X86 and Sparc with the JIT.
2. What algorithms are used to identify hot loop regions and hot paths for
runtime reoptimization?
3. How to relate identified executing native code (of hot loops and
regions) back to original LLVM bytecode?
4. What runtime optimizations are applied in the current version?
Currently we do not perform any profile-driven runtime optimizations in
the JIT, though it would not be hard at all to do so (we already have the
profiling framework, it's just a matter of plugging them together).
There is also an internal project, known as the "reoptimizer", which does
do runtime reoptimization of programs, but others know more about it than
I.
Would it be possible to provide a more detailed document? If not
convenient, please give us a brief description of files which are in
charge of these functions. I appreciate your effort and time. Thanks.
All of the JIT specific code lives in lib/ExecutionEngine/JIT. The code
shared between it and the interpreter lives in lib/ExecutionEngine. The
JIT also depends on support from a target-specific code generator, which
live in lib/Target/<architecture>.
-Chris