search for: currentdebugtype

Displaying 13 results from an estimated 13 matches for "currentdebugtype".

2009 Jan 21
3
[LLVMdev] Load from abs address generated bad code on LLVM 2.4
...possible. Even the tiny >> test case I posted doesn't work with the latest version: there >> were changes needed to get it to compile. Also, I can no longer >> figure out how to turn on debugging dumps in the JIT. The simple >> >> DebugFlag = true; >> CurrentDebugType = "x86-emitter"; >> >> no longer works, and there seems to be no replacement for it. > > That should work fine, just use "jit" instead of "x86-emitter" as the > debug type. That's impossible: CurrentDebugType is now private; it appears nowh...
2009 Jan 20
2
[LLVMdev] Load from abs address generated bad code on LLVM 2.4
...so simply upgrading to the latest release isn't possible. Even the tiny test case I posted doesn't work with the latest version: there were changes needed to get it to compile. Also, I can no longer figure out how to turn on debugging dumps in the JIT. The simple DebugFlag = true; CurrentDebugType = "x86-emitter"; no longer works, and there seems to be no replacement for it. Andrew.
2009 Jan 20
0
[LLVMdev] Load from abs address generated bad code on LLVM 2.4
...latest release isn't possible. Even the tiny > test case I posted doesn't work with the latest version: there > were changes needed to get it to compile. Also, I can no longer > figure out how to turn on debugging dumps in the JIT. The simple > > DebugFlag = true; > CurrentDebugType = "x86-emitter"; > > no longer works, and there seems to be no replacement for it. That should work fine, just use "jit" instead of "x86-emitter" as the debug type. -Chris
2009 Jan 21
0
[LLVMdev] Load from abs address generated bad code on LLVM 2.4
On Jan 21, 2009, at 4:15 AM, Andrew Haley wrote: >> That should work fine, just use "jit" instead of "x86-emitter" as the >> debug type. > > That's impossible: CurrentDebugType is now private; it appears > nowhere in the installed headers. I can't find any public interface > to allow a JIT to set it. Ah ok. I'd suggest doing what llvm-gcc does here, it is a much more stable API: std::vector<const char*> Args; Args.push_back(""); /...
2009 Dec 21
2
[LLVMdev] [PATCH] Implement dbgs()
...cl::desc("Buffer the last N characters of debug output" + "until program termination. " + "[default 0 -- immediate print-out]"), + cl::Hidden, + cl::init(0)); + static std::string CurrentDebugType; static struct DebugOnlyOpt { void operator=(const std::string &Val) const { @@ -50,6 +63,18 @@ cl::Hidden, cl::value_desc("debug string"), cl::location(DebugOnlyOptLoc), cl::ValueRequired); +// Signal handlers - dump debug output on termination. +static vo...
2009 Jan 22
1
[LLVMdev] JIT debug dumps [Was Re: Load from abs address generated bad code on LLVM 2.4]
Chris Lattner wrote: > On Jan 21, 2009, at 4:15 AM, Andrew Haley wrote: >>> That should work fine, just use "jit" instead of "x86-emitter" as the >>> debug type. >> That's impossible: CurrentDebugType is now private; it appears >> nowhere in the installed headers. I can't find any public interface >> to allow a JIT to set it. > > Ah ok. I'd suggest doing what llvm-gcc does here, it is a much more > stable API: > > std::vector<const char*> Args; &...
2009 Dec 19
0
[LLVMdev] [PATCH] Implement dbgs()
On Dec 18, 2009, at 6:36 PM, David Greene wrote: >>> +// Signal handlers - dump debug output on termination. >>> +static void debug_user_sig_handler(void *Cookie) >>> +{ >>> + llvm::circular_raw_ostream *logout = >>> + dynamic_cast<llvm::circular_raw_ostream *>(&llvm::dbgs()); >> >> Please do not use dynamic_cast, we're
2009 Dec 21
0
[LLVMdev] [PATCH] Implement dbgs()
On 2009-12-21 18:06, David Greene wrote: > On Saturday 19 December 2009 00:16, Chris Lattner wrote: > > >>> Or I think I can just assume (Yikes!) that if the signal handler is >>> invoked it will really be a circular_raw_ostream since the handler >>> should (!) only be set up in debug mode. >>> >>> That scares me a bit, though. >>>
2009 Dec 21
2
[LLVMdev] [PATCH] Implement dbgs()
...cl::desc("Buffer the last N characters of debug output" + "until program termination. " + "[default 0 -- immediate print-out]"), + cl::Hidden, + cl::init(0)); + static std::string CurrentDebugType; static struct DebugOnlyOpt { void operator=(const std::string &Val) const { @@ -50,6 +63,18 @@ cl::Hidden, cl::value_desc("debug string"), cl::location(DebugOnlyOptLoc), cl::ValueRequired); +// Signal handlers - dump debug output on termination. +static vo...
2009 Dec 19
3
[LLVMdev] [PATCH] Implement dbgs()
On Friday 18 December 2009 19:56, Chris Lattner wrote: > > +// -debug-buffer-size - This is a command line op0tion to set the > > size > > +// of the debug stream circular buffer. The value is the number of > > +// characters to save. > > +static cl::opt<unsigned> > > +DebugBufferSize("debug-buffer-size", > > +
2009 Dec 18
2
[LLVMdev] [PATCH] Implement dbgs()
...tatic cl::opt<unsigned> +DebugBufferSize("debug-buffer-size", + llvm::cl::desc("Save last N characters of debug output " + "[default 0--immediate print-out]"), + llvm::cl::init(0)); + static std::string CurrentDebugType; static struct DebugOnlyOpt { void operator=(const std::string &Val) const { @@ -50,6 +62,16 @@ cl::Hidden, cl::value_desc("debug string"), cl::location(DebugOnlyOptLoc), cl::ValueRequired); +// Signal handlers - dump debug output on termination. +static vo...
2009 Jan 19
6
[LLVMdev] Load from abs address generated bad code on LLVM 2.4
...odule (); Function *foo; int main (int argc, char **argv) { Module *Mod = makeLLVMModule (); verifyModule (*Mod, PrintMessageAction); PassManager PM; PM.add (new PrintModulePass ()); PM.run (*Mod); ExecutionEngine *engine = ExecutionEngine ::create(Mod); // DebugFlag = true; // CurrentDebugType = "x86-emitter"; typedef int (*pf)(); pf F = (pf)engine->getPointerToFunction(foo); int res = F(); printf ("ret = %d\n", res); delete Mod; return 0; } int32_t p = 99; Module * makeLLVMModule () { // Module Construction Module *mod = new Module ("test...
2009 Jan 19
0
[LLVMdev] Load from abs address generated bad code on LLVM 2.4
On Jan 19, 2009, at 7:55 AM, Andrew Haley wrote: > This is x86_64. I have a problem where an absolute memory load > The current LLVM trunk does not have this bug. This seems quite a > nasty > bug; is there any chance of a bug-fix release for LLVM 2.4, or > should I > just use LLVM trunk until LLVM 2.5 ? Hi Andrew, As others have pointed out, using a global and