Displaying 13 results from an estimated 13 matches for "currentdebugtyp".
Did you mean:
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
now...
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 v...
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 v...
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 v...
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 ("tes...
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