Re: [lldb-dev] [BUG] Many lookup failures

[David Blaikie via lldb-dev]

On Mon, Nov 30, 2015 at 1:57 PM, Eric Christopher 
wrote:

>
>
> On Mon, Nov 30, 2015 at 9:41 AM Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> So be sure to enable -fno-limit-debug-info to make sure the compiler
>> isn't emitting lame debug info.
>>
>>
> Greg cannot be more wrong here. There are some limitations to be aware of
> when using limit debug info, but if the debug info exists for the type in
> the object and debug info then it's the fault of the debugger.  The
> limitations are pretty well defined, which is "if you ship the debug info
> for all parts of the project you've just built then it should work just
> fine". It isn't clear whether or not this is the case here, but the
> compiler isn't "emitting lame debug info". (Also, it's not clear which
> compiler you're using anyhow so Greg's advice is doubly bad).
>
> -eric
>
>
>
>
>> If things are still failing, check to see what we think "CG::Node"
>> contains by dumping the type info for it:
>>
>> (lldb) image lookup -t CG::Node
>>
>> This will print out the complete class definition that we have for
>> "CG::Node" including ivars and methods. You should be able to see the
>> inheritance structure and you might need to also dump the type info for
>> each inherited class.
>>
>> Compilers have been trying to not output a bunch of debug info and in the
>> process they started to omit class info for base classes. So if you have:
>>
>> class A : public B
>> {
>> };
>>
>> where class "B" has all sorts of interesting methods, the debug info will
>> often look like:
>>
>> class B; // Forward declaration for class B
>>
>> class A : public B
>> {
>> };
>>
>> When this happens, we must make class A in a clang::ASTContext in
>> DWARFASTParserClang and if "B" is a forward declaration, we can't leave it
>> as a forward declaration or clang will assert and kill the debugger, so
>> currently we just say "oh well, the compiler gave us lame debug info, and
>> clang will crash if we don't fix this, so I am going to pretend we have a
>> definition for class B and it contains nothing".
>>
>
Why not lookup the definition of B in the debug info at this point rather
than making a stub/empty definition? (& if there is none, then, yes, I
suppose an empty definition of B is as good as anything, maybe - it's going
to produce some weird results, maybe)


> I really don't like that the compiler thinks this is OK to do, but that is
>> the reality and we have to deal with it.
>>
>
GCC's been doing it for a while longer than Clang & it represents a
substantial space savings in debug info size - it'd be hard to explain to
users why Clang's debug info is so much (20% or more) larger than GCC's
when GCC's contains all the information required and GDB gives a good user
experience with that information and LLDB does not.


> So the best thing I can offer it you must use -fno-limit-debug-info when
>> compiling to stop the compiler from doing this and things should be back to
>> normal for you. If this isn't what is happening, let us know what the
>> "image lookup -t" output looks like and we can see what we can do.
>>
>> Greg Clayton
>> > On Nov 25, 2015, at 10:00 AM, Ramkumar Ramachandra via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> >
>> > Hi,
>> >
>> > Basic things are failing.
>> >
>> > (lldb) p lhs
>> > (CG::VarExpr *) $0 = 0x00010d445ca0
>> > (lldb) p lhs->rootStmt()
>> > (CG::ExprStmt *) $1 = 0x00010d446290
>> > (lldb) p cg_pp_see_it(lhs->rootStmt())
>> > (const char *) $2 = 0x00010d448020 "%A = $3;"
>> > (lldb) p cg_pp_see_it(def->rootStmt())
>> > error: no member named 'rootStmt' in 'CG::Node'
>> > error: 1 errors parsing expression
>> > (lldb) p cg_pp_see_it(def)
>> > error: no matching function for call to 'cg_pp_see_it'
>> > note: candidate function not viable: no known conversion from
>> > 'CG::Node *' to 'CG_Obj *' for 1st argument
>> > error: 1 errors parsing expression
>> >
>> > It's total junk; why can't it see the inheritance VarExpr -> Node ->
>> > CG_Obj? The worst part is that rootStmt() is a function defined on
>> > Node!
>> >
>> > Ram
>> > ___
>> > lldb-dev mailing list
>> > lldb-dev@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [BUG] Many lookup failures

[Eric Christopher via lldb-dev]

On Mon, Nov 30, 2015 at 9:41 AM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> So be sure to enable -fno-limit-debug-info to make sure the compiler isn't
> emitting lame debug info.
>
>
Greg cannot be more wrong here. There are some limitations to be aware of
when using limit debug info, but if the debug info exists for the type in
the object and debug info then it's the fault of the debugger.  The
limitations are pretty well defined, which is "if you ship the debug info
for all parts of the project you've just built then it should work just
fine". It isn't clear whether or not this is the case here, but the
compiler isn't "emitting lame debug info". (Also, it's not clear which
compiler you're using anyhow so Greg's advice is doubly bad).

-eric




> If things are still failing, check to see what we think "CG::Node"
> contains by dumping the type info for it:
>
> (lldb) image lookup -t CG::Node
>
> This will print out the complete class definition that we have for
> "CG::Node" including ivars and methods. You should be able to see the
> inheritance structure and you might need to also dump the type info for
> each inherited class.
>
> Compilers have been trying to not output a bunch of debug info and in the
> process they started to omit class info for base classes. So if you have:
>
> class A : public B
> {
> };
>
> where class "B" has all sorts of interesting methods, the debug info will
> often look like:
>
> class B; // Forward declaration for class B
>
> class A : public B
> {
> };
>
> When this happens, we must make class A in a clang::ASTContext in
> DWARFASTParserClang and if "B" is a forward declaration, we can't leave it
> as a forward declaration or clang will assert and kill the debugger, so
> currently we just say "oh well, the compiler gave us lame debug info, and
> clang will crash if we don't fix this, so I am going to pretend we have a
> definition for class B and it contains nothing".
>
> I really don't like that the compiler thinks this is OK to do, but that is
> the reality and we have to deal with it.
>
> So the best thing I can offer it you must use -fno-limit-debug-info when
> compiling to stop the compiler from doing this and things should be back to
> normal for you. If this isn't what is happening, let us know what the
> "image lookup -t" output looks like and we can see what we can do.
>
> Greg Clayton
> > On Nov 25, 2015, at 10:00 AM, Ramkumar Ramachandra via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi,
> >
> > Basic things are failing.
> >
> > (lldb) p lhs
> > (CG::VarExpr *) $0 = 0x00010d445ca0
> > (lldb) p lhs->rootStmt()
> > (CG::ExprStmt *) $1 = 0x00010d446290
> > (lldb) p cg_pp_see_it(lhs->rootStmt())
> > (const char *) $2 = 0x00010d448020 "%A = $3;"
> > (lldb) p cg_pp_see_it(def->rootStmt())
> > error: no member named 'rootStmt' in 'CG::Node'
> > error: 1 errors parsing expression
> > (lldb) p cg_pp_see_it(def)
> > error: no matching function for call to 'cg_pp_see_it'
> > note: candidate function not viable: no known conversion from
> > 'CG::Node *' to 'CG_Obj *' for 1st argument
> > error: 1 errors parsing expression
> >
> > It's total junk; why can't it see the inheritance VarExpr -> Node ->
> > CG_Obj? The worst part is that rootStmt() is a function defined on
> > Node!
> >
> > Ram
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [BUG] Many lookup failures

[Greg Clayton via lldb-dev]

So the main question is probably that you have a "CG::Node" and it inherits 
from one or more other classes and we probably either didn't find definitions 
for one or more of these classes. I would like to verify this to make sure we 
understand the problem. Can you do a:

(lldb) image dump -t "CG::Node"

And then see what classes it inherits from by looking at the textual version of 
the class that gets dumped. And repeat the "image dump -t " for each 
class that "CG::Node" inherits from and let me know if any of these classes are 
empty (no methods or ivars) when they shouldn't be empty? 

The theory behind the compiler debug info reduction that is enabled by default 
(-flimit-debug-info) is there should be an actual definition of the base 
classes somewhere and the debugger should be able to find it. We need to 
determine if this is the case for this binary. There could be an LLDB bug where 
there is debug info for the base class, but LLDB doesn't find it. The main 
issue the debugger has with the reduced debug info is we don't currently look 
across shared library boundaries when creating the type from the debug info. So 
if you have "CG::Node" in one shared library (liba.so) and it inherits from 
"Bar" that is in another shared library (libb.so) we will run into this problem 
as the compiler might emit a forward declaration for "Bar" in the debug info 
for liba.so. When we debug, we might have the debug info from libb.so or we 
might not, so even if we are able to fix LLDB to mark classes that it has 
completed just to keep clang from asserting, we might not be able to fix up the 
debug info to make it work when debugging later. This is why I prefer to have 
the information up front even though it might be duplicated elsewhere. There 
are many valid reasons for reducing the size of debug info: compile times and 
link timers are shorter, debug info size is smaller, and more.

Greg



> On Nov 30, 2015, at 9:41 AM, Greg Clayton via lldb-dev 
>  wrote:
> 
> So be sure to enable -fno-limit-debug-info to make sure the compiler isn't 
> emitting lame debug info. 
> 
> If things are still failing, check to see what we think "CG::Node" contains 
> by dumping the type info for it:
> 
> (lldb) image lookup -t CG::Node
> 
> This will print out the complete class definition that we have for "CG::Node" 
> including ivars and methods. You should be able to see the inheritance 
> structure and you might need to also dump the type info for each inherited 
> class.
> 
> Compilers have been trying to not output a bunch of debug info and in the 
> process they started to omit class info for base classes. So if you have:
> 
> class A : public B
> {
> };
> 
> where class "B" has all sorts of interesting methods, the debug info will 
> often look like:
> 
> class B; // Forward declaration for class B
> 
> class A : public B
> {
> };
> 
> When this happens, we must make class A in a clang::ASTContext in 
> DWARFASTParserClang and if "B" is a forward declaration, we can't leave it as 
> a forward declaration or clang will assert and kill the debugger, so 
> currently we just say "oh well, the compiler gave us lame debug info, and 
> clang will crash if we don't fix this, so I am going to pretend we have a 
> definition for class B and it contains nothing".
> 
> I really don't like that the compiler thinks this is OK to do, but that is 
> the reality and we have to deal with it. 
> 
> So the best thing I can offer it you must use -fno-limit-debug-info when 
> compiling to stop the compiler from doing this and things should be back to 
> normal for you. If this isn't what is happening, let us know what the "image 
> lookup -t" output looks like and we can see what we can do.
> 
> Greg Clayton
>> On Nov 25, 2015, at 10:00 AM, Ramkumar Ramachandra via lldb-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> Basic things are failing.
>> 
>> (lldb) p lhs
>> (CG::VarExpr *) $0 = 0x00010d445ca0
>> (lldb) p lhs->rootStmt()
>> (CG::ExprStmt *) $1 = 0x00010d446290
>> (lldb) p cg_pp_see_it(lhs->rootStmt())
>> (const char *) $2 = 0x00010d448020 "%A = $3;"
>> (lldb) p cg_pp_see_it(def->rootStmt())
>> error: no member named 'rootStmt' in 'CG::Node'
>> error: 1 errors parsing expression
>> (lldb) p cg_pp_see_it(def)
>> error: no matching function for call to 'cg_pp_see_it'
>> note: candidate function not viable: no known conversion from
>> 'CG::Node *' to 'CG_Obj *' for 1st argument
>> error: 1 errors parsing expression
>> 
>> It's total junk; why can't it see the inheritance VarExpr -> Node ->
>> CG_Obj? The worst part is that rootStmt() is a function defined on
>> Node!
>> 
>> Ram
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> 

[lldb-dev] reply: reply?? lldb debug jit-compiled code with llvm on windows

[haifeng_q via lldb-dev]

Question 1:
On the windows, I use the code implements a function (see debug_target.cpp) of 
JIT (see debug_target_process.cpp), but when generating debug information, no 
production .symtab section for information that leads LLDB get JIT debugging 
information .symtab failure , and then set a breakpoint to fail.
  LLDB command: lldb_result.txt
 JIT compilation results: debug_target.ll
  
  Question 2:
 How JIT debugging supported on Linux?
  
  thanks!

 

 -- The original message --
  From: "Zachary Turner";;
 Data: 2015??11??21?? AM 0:10
 Receive: "Tamas Berghammer"; " 
"; "lldb-dev"; 
 
 Title: Re: [lldb-dev] reply?? lldb debug jit-compiled code with llvm on windows

 

 Can you also try clang-cl and see if it works?

  On Fri, Nov 20, 2015 at 3:02 AM Tamas Berghammer via lldb-dev 
 wrote:

  I don't know how JIT debugging should work on WIndows with MSVC but I don't 
think LLDB support it in any way. What I wrote should be true on Linux (and on 
some related) systems. You might be able to get the same results on Windows if 
you use lli (LLVM based JIT runner) but I have no knowledge if it will work or 
not.

  On Fri, Nov 20, 2015 at 8:56 AM haifeng_q  wrote:

  My analysis of the code, the reasons are:
  
  Since the debugging process is MSVC compiler, there is no DWARF debugging 
information. So lldb get __jit_debug_register_code and __it_debug_descriptor 
symbol debugging process fails, and __jit_debug_register_code not support MSVC.

 I do not know whether correct?
 

 -- original message--
  From:"Tamas Berghammer";tbergham...@google.com;
 Date:2015??11??19?? PM 8:37
 receive: " "; "lldb-dev"; 
 
 Subject: Re: [lldb-dev] lldb debug jit-compiled code with llvm on windows

 

 In theory you don't have to do anything special to debug some JIT-ed code as 
everything should just work (based on the gdb jit interface). In practice I 
tried it out a few days ago and it wasn't working at all even in the case when 
the application is launched under LLDB (not with attach). LLDB was 
understanding the eh_frame for the JIT-ed code but didn't found the debug info 
for unknown reason. We should investigate it and try to fix it sometime. We 
(lldb for android developers) plan to do it sometime but if you are interested 
in it then please feel free to take a look and let us know if you have any 
question.  

 Tamas


  On Thu, Nov 19, 2015 at 8:40 AM haifeng_q via lldb-dev 
 wrote:

  hi,
 process A generate function Func1 code with llvm jit compiler, and calls 
Func1. modeled on "Kaleidoscope: Adding Debug Information" add debug 
information. how to use LLDB to attach process A to debug this function, add a 
breakpoint in the function?
  
 thanks!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

 


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

debug_target.cpp
Description: Binary data


debug_target.ll
Description: Binary data


debug_target_process.cpp
Description: Binary data


lldb_result.txt
Description: Binary data


lldb_stack.txt
Description: Binary data
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] static swig bindings and xcode workspace

[Zachary Turner via lldb-dev]

Has the xcode build been changed to use static bindings yet?  I got to
thinking that maybe it would make sense to put them alongside the xcode
workspace folders, just to emphasize that the static bindings were an
artifact of how the xcode build works.  This way we just say "Xcode build
uses static bindings" and "CMake build needs an installed swig", and this
is enforced at the directory level.

In order to do this you'd have to probably make a new toplevel folder to
house both the lldb.xcodeproj and lldb.xcworkspace folders, but I think
that would be useful for other reasons as well.  For example, I want to
check in a visual studio python solution for the test suite at some point,
and it would make sense if all of this additional stuff was in one place.
So perhaps something like:

lldb
|__ contrib
|__ xcode
|__ LLDBWrapPython.cpp
|__ lldb.py
|__ lldb.xcodeproj
|__ lldb.xcworkspace
|__ msvc

I have been thinking about this idea of a contrib folder for a while
anyway, but wanted to have more reasons to make use of it before I brought
it up.

Good idea?  Bad idea?  Thoughts?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Inquiry about .debug_frame

[Greg Clayton via lldb-dev]

Most compilers emit the same thing for EH frame and for .debug_frame. If this 
does indeed differ, then LLDB should parse both, but any such changes should 
really do so in a way that prefers .debug_frame over .eh_frame since 
.debug_frame should be complete unwind info even though it is just he same as 
the .eh_frame for most compilers.


> On Nov 24, 2015, at 5:50 AM, Ravitheja Addepally via lldb-dev 
>  wrote:
> 
> Hello,
>While compiling with clang for i386, I notice that the CFI information 
> is distributed between the .eh_frame section and the .debug_frame section, 
> meaning for some functions the CFI info is present in the .debug_frame 
> section whereas for some it is present in the .eh_frame. Now looking at the 
> lldb code,  I see that this information is only read from the .eh_frame 
> section and not from the .debug_frame section. My questions are the following 
> ->
> 1) Is there something that I missing ? is the  information that I provided in 
> this email correct ?
> 2) If it is correct, is this expected behavior ? I mean if the CFI info is 
> present in the .debug_frame then I think it should be read ? coz it maybe 
> useful in unwinding scenarios ?
> 
> 
> BR,
> A Ravi
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Linux core dump doesn't show listing when loaded

[Greg Clayton via lldb-dev]

"thread list" should just list the threads and their stop reasons (no 
backtraces). If you want backtraces just do "thread backtrace all".


On Nov 24, 2015, at 1:09 PM, Ted Woodward via lldb-dev 
 wrote:
> 
> I’ve been working on an old rev that we’d released on; now I’m much closer to 
> ToT as we move towards our next major Hexagon release.
>  
> Core dumps on the old rev would print out a listing/disassembly for each 
> thread in the core dump. Now it doesn’t.
>  
> ToT does this, on x86 Linux:
>  
> >bin/lldb ~/lldb_test/coredump/lincrash -c ~/lldb_test/coredump/lincore
> (lldb) target create "/usr2/tedwood/lldb_test/coredump/lincrash" --core 
> "/usr2/tedwood/lldb_test/coredump/lincore"
> Core file '/usr2/tedwood/lldb_test/coredump/lincore' (x86_64) was loaded.
> (lldb) thread list
> Process 0 stopped
> * thread #1: tid = 0, 0x00401190 lincrash`main + 16 at lincrash.c:5, 
> name = 'lincrash', stop reason = signal SIGSEGV
> (lldb)
>  
> I can see the listing by going up and down the stack, but I’d like to see the 
> listing on load. Is the no listing intended?
>  
> Ted
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>  
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [BUG] Many lookup failures

[Greg Clayton via lldb-dev]

So be sure to enable -fno-limit-debug-info to make sure the compiler isn't 
emitting lame debug info. 

If things are still failing, check to see what we think "CG::Node" contains by 
dumping the type info for it:

(lldb) image lookup -t CG::Node

This will print out the complete class definition that we have for "CG::Node" 
including ivars and methods. You should be able to see the inheritance 
structure and you might need to also dump the type info for each inherited 
class.

Compilers have been trying to not output a bunch of debug info and in the 
process they started to omit class info for base classes. So if you have:

class A : public B
{
};

where class "B" has all sorts of interesting methods, the debug info will often 
look like:

class B; // Forward declaration for class B

class A : public B
{
};

When this happens, we must make class A in a clang::ASTContext in 
DWARFASTParserClang and if "B" is a forward declaration, we can't leave it as a 
forward declaration or clang will assert and kill the debugger, so currently we 
just say "oh well, the compiler gave us lame debug info, and clang will crash 
if we don't fix this, so I am going to pretend we have a definition for class B 
and it contains nothing".

I really don't like that the compiler thinks this is OK to do, but that is the 
reality and we have to deal with it. 

So the best thing I can offer it you must use -fno-limit-debug-info when 
compiling to stop the compiler from doing this and things should be back to 
normal for you. If this isn't what is happening, let us know what the "image 
lookup -t" output looks like and we can see what we can do.

Greg Clayton
> On Nov 25, 2015, at 10:00 AM, Ramkumar Ramachandra via lldb-dev 
>  wrote:
> 
> Hi,
> 
> Basic things are failing.
> 
> (lldb) p lhs
> (CG::VarExpr *) $0 = 0x00010d445ca0
> (lldb) p lhs->rootStmt()
> (CG::ExprStmt *) $1 = 0x00010d446290
> (lldb) p cg_pp_see_it(lhs->rootStmt())
> (const char *) $2 = 0x00010d448020 "%A = $3;"
> (lldb) p cg_pp_see_it(def->rootStmt())
> error: no member named 'rootStmt' in 'CG::Node'
> error: 1 errors parsing expression
> (lldb) p cg_pp_see_it(def)
> error: no matching function for call to 'cg_pp_see_it'
> note: candidate function not viable: no known conversion from
> 'CG::Node *' to 'CG_Obj *' for 1st argument
> error: 1 errors parsing expression
> 
> It's total junk; why can't it see the inheritance VarExpr -> Node ->
> CG_Obj? The worst part is that rootStmt() is a function defined on
> Node!
> 
> Ram
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [BUG] Many lookup failures

[Ramkumar Ramachandra via lldb-dev]

On Mon, Nov 30, 2015 at 12:41 PM, Greg Clayton  wrote:
> class A : public B
> {
> };
>
> where class "B" has all sorts of interesting methods, the debug info will 
> often look like:
>
> class B; // Forward declaration for class B
>
> class A : public B
> {
> };

What? Didn't we just fix this (for the case where there's conflicting
debug info from two different libraries)?

(lldb) image lookup -t ...

prints expected results, with no empty classes. Let me emphasize that
the strange behavior is seen with _some_ variables: in the debugging
session referenced in the original email, the problem was particularly
bad.

I didn't try the expensive experiment (-fno-limit-debug-info) on
account of lldb finding all the classes in full.

Is there some systematic way to test lldb? [Looks in the unittests/
and test/ directories]
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] ThreadPlanStepOverBreakpoint behavior

[Jim Ingham via lldb-dev]

Eh, should probably actually say something, no...

Would it be sufficient to call 
ThreadPlanStepOverBreakpoint::ReenableBreakpointSite to reenable the breakpoint 
you were stepping over in ThreadPlanStepOverBreakpoint::WillPop?  It won't hurt 
to enable it twice, once in MischiefManaged and once in WillPop.  You might 
even get away with doing it only in WillPop and not in MischiefManaged, since 
no other thread plans are consulted between MischiefManaged and WillPop.  The 
fact that you've moved the re-enabling from MM to WP should not be detectable.  
And it seems wrong that you should be able to get rid of a "StepOverBreakpoint" 
plan without re-enabling the breakpoint, so this was clearly just an oversite.

BTW, you don't want to change the stop reason to trace.  Instruction single 
stepping onto a breakpoint, and actually hitting the breakpoint should look the 
same to the higher layers of the debugger.

Jim


> On Nov 30, 2015, at 5:24 PM, Jim Ingham via lldb-dev 
>  wrote:
> 
> 
>> On Nov 25, 2015, at 1:05 PM, Philippe Lavoie  
>> wrote:
>> 
>> Sorry for the delay, I revisited the issue today.
>> 
>> It is causing a problem for our architecture which does not support single 
>> instruction stepping. We emulate it with breakpoints and a processor 
>> exception on branch taken.
>> 
>> For example:
>> 
>> When we step over a line with a breakpoint, our flavor of StepOverRange 
>> inserts a breakpoint at the next likely instruction and enables processor 
>> branch exception. LLDB will queue StepOverRange and StepOverBreakpoint plans.
>> 
>> The problem occurs when we stop on the breakpoint inserted by StepOverRange. 
>> ThreadPlanStepOverBreakpoint::DoPlanExplainsStop will see the stop reason is 
>> eStopReasonBreakpoint and ignore the breakpoint. Then StepOverRange's 
>> DoPlanExplainsStop will claim it and ThreadPlanStepOverBreakpoint gets 
>> discarded and does not reinsert the original breakpoint.
>> 
>> Is there a way to make our scenario fit in the default thread plans?
>> Maybe check the breakpoint kind of all 'step' breakpoints and set the 
>> thread's StopReason to Trace?
>> 
>> -Philippe
>> 
>> From: jing...@apple.com [jing...@apple.com]
>> Sent: Monday, October 05, 2015 5:26 PM
>> To: Philippe Lavoie
>> Cc: lldb-dev@lists.llvm.org
>> Subject: Re: [lldb-dev] ThreadPlanStepOverBreakpoint behavior
>> 
>> That is intended behavior.  MischiefManaged is called when an stop 
>> propagates to that plan, and it needs to decide whether it is done or not.  
>> That’s not what happens when somebody decides to discard the plan.  WillPop 
>> will get called if you need to do some cleanup when the plan gets popped.
>> 
>> Was this causing some problem?
>> 
>> Jim
>> 
>>> On Sep 25, 2015, at 1:51 PM, Philippe Lavoie via lldb-dev 
>>>  wrote:
>>> 
>>> 
>>> I noticed that when a ThreadPlanStepOverBreakpoint is discarded (as opposed 
>>> to being popped from the stack), MischiefManaged() is not called and the 
>>> disabled breakpoint is not re-enabled.
>>> 
>>> Is this the intended behavior ?
>>> 
>>> -Philippe
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [BUG] Many lookup failures

[David Blaikie via lldb-dev]

On Mon, Nov 30, 2015 at 6:04 PM, Ramkumar Ramachandra 
wrote:

> On Mon, Nov 30, 2015 at 5:42 PM, Greg Clayton  wrote:
> > When we debug "a.out" again, we might have recompiled "liba.so", but not
> "libb.so" and when we debug again, we don't need to reload the debug info
> for "libb.so" if it hasn't changed, we just reload "liba.so" and its debug
> info. When we rerun a target (run a.out again), we don't need to spend any
> time reloading any shared libraries that haven't changed since they are
> still in our global shared library cache. So to keep this global library
> cache clean, we don't allow types from another shared library (libb.so) to
> be loaded into another (liba.so), otherwise we wouldn't be able to reap the
> benefits of our shared library cache as we would always need to reload
> debug info every time we run.
>
> Tangential: gdb starts up significantly faster than lldb. I wonder
> what lldb is doing wrong.
>
> Oh, this is if I use the lldb that Apple supplied. If I compile my own
> lldb with llvm-release, clang-release, and lldb-release, it takes like
> 20x the time to start up: why is this? And if I use llvm-debug,
> clang-debug, lldb-debug, the time it takes is completely unreasonable.
>

If you built your own you probably built a +Asserts build which slows
things down a lot. You'll want to make sure you're building Release-Asserts
(Release "minus" Asserts) builds if you want them to be usable.


>
> > LLDB currently recreates types in a clang::ASTContext and this imposes
> much stricter rules on how we represent types which is one of the
> weaknesses of the LLDB approach to type representation as the clang
> codebase often asserts when it is not happy with how things are
> represented. This does payoff IMHO in the complex expressions we can
> evaluate where we can use flow control, define and use C++ lambdas, and
> write more than one statement when writing expressions. But it is
> definitely a tradeoff. GDB has its own custom type representation which can
> be better for dealing with the different kinds and completeness of debug
> info, but I am comfortable with our approach.
>
> Yeah, about that. I question the utility of evaluating crazy
> expressions in lldb: I've not felt the need to do that even once, and
> I suspect a large userbase is with me on this. What's important is
> that lldb should _never_ fail to inspect a variable: isn't this the #1
> job of the debugger?
>

Depends on the language - languages with more syntactic sugar basically
need crazy expression evaluation to function very well in a debugger for
the average user. (evaluating operator overloads in C++ expressions, just
being able to execute non-trivial pretty-printers for interesting types
(std::vector being a simple example, or a small-string optimized
std::string, etc - let alone examples in ObjC or even Swift))

- Dave
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [BUG] Many lookup failures

[Greg Clayton via lldb-dev]

> 
> This will print out the complete class definition that we have for "CG::Node" 
> including ivars and methods. You should be able to see the inheritance 
> structure and you might need to also dump the type info for each inherited 
> class.
> 
> Compilers have been trying to not output a bunch of debug info and in the 
> process they started to omit class info for base classes. So if you have:
> 
> class A : public B
> {
> };
> 
> where class "B" has all sorts of interesting methods, the debug info will 
> often look like:
> 
> class B; // Forward declaration for class B
> 
> class A : public B
> {
> };
> 
> When this happens, we must make class A in a clang::ASTContext in 
> DWARFASTParserClang and if "B" is a forward declaration, we can't leave it as 
> a forward declaration or clang will assert and kill the debugger, so 
> currently we just say "oh well, the compiler gave us lame debug info, and 
> clang will crash if we don't fix this, so I am going to pretend we have a 
> definition for class B and it contains nothing".
> 
> Why not lookup the definition of B in the debug info at this point rather 
> than making a stub/empty definition? (& if there is none, then, yes, I 
> suppose an empty definition of B is as good as anything, maybe - it's going 
> to produce some weird results, maybe)

LLDB creates types using only the debug info from the currently shared library 
and we don't take a copy of a type from another shared library when creating 
the types for a given shared library. Why? LLDB has a global repository of 
modules (the class that represents an executable or shared library in LLDB). If 
Xcode, or any other IDE that can debug more that one thing at a time has two 
targets: "a.out" and "b.out", they share all of the shared library modules so 
that if debug info has already been parsed in the target for "a.out" for the 
shared library "liba.so" (or any other shared library), then the "b.out" target 
has the debug info already loaded for "liba.so" because "a.out" already loaded 
that module (LLDB runs in the same address space as our IDE). This means that 
all debug info in LLDB currently creates types using only the info in the 
current shared library. When we debug "a.out" again, we might have recompiled 
"liba.so", but not "libb.so" and when we debug again, we don't need to reload 
the debug info for "libb.so" if it hasn't changed, we just reload "liba.so" and 
its debug info. When we rerun a target (run a.out again), we don't need to 
spend any time reloading any shared libraries that haven't changed since they 
are still in our global shared library cache. So to keep this global library 
cache clean, we don't allow types from another shared library (libb.so) to be 
loaded into another (liba.so), otherwise we wouldn't be able to reap the 
benefits of our shared library cache as we would always need to reload debug 
info every time we run. 

LLDB does have the ability, when displaying types, to grab types from the best 
source (other shared libraries), we just don't transplant types in the LLDB 
shared library objects (lldb_private::Module) versions of the types. We do 
currently assume that all classes that aren't pointers or references (or other 
types that can legally have forward declarations of structs or classes) are 
complete in our current model. 

There are modifications we can do to LLDB to deal with the partial debug info 
and possible lack thereof when the debug info for other shared libraries are 
not present, but we haven't done this yet in LLDB.

>  
> I really don't like that the compiler thinks this is OK to do, but that is 
> the reality and we have to deal with it.
> 
> GCC's been doing it for a while longer than Clang & it represents a 
> substantial space savings in debug info size - it'd be hard to explain to 
> users why Clang's debug info is so much (20% or more) larger than GCC's when 
> GCC's contains all the information required and GDB gives a good user 
> experience with that information and LLDB does not.

LLDB currently recreates types in a clang::ASTContext and this imposes much 
stricter rules on how we represent types which is one of the weaknesses of the 
LLDB approach to type representation as the clang codebase often asserts when 
it is not happy with how things are represented. This does payoff IMHO in the 
complex expressions we can evaluate where we can use flow control, define and 
use C++ lambdas, and write more than one statement when writing expressions. 
But it is definitely a tradeoff. GDB has its own custom type representation 
which can be better for dealing with the different kinds and completeness of 
debug info, but I am comfortable with our approach.

So we need to figure out what the root problem is here before we can go further 
and talk about any additional solutions or fixes that may be required.

Greg

>  
> So the best thing I can offer it you must use -fno-limit-debug-info when 
> compiling to stop the compiler from doing this 

Re: [lldb-dev] [BUG] Many lookup failures

[Greg Clayton via lldb-dev]

> On Nov 30, 2015, at 2:54 PM, David Blaikie  wrote:
> 
> 
> 
> On Mon, Nov 30, 2015 at 2:42 PM, Greg Clayton  wrote:
> >
> > This will print out the complete class definition that we have for 
> > "CG::Node" including ivars and methods. You should be able to see the 
> > inheritance structure and you might need to also dump the type info for 
> > each inherited class.
> >
> > Compilers have been trying to not output a bunch of debug info and in the 
> > process they started to omit class info for base classes. So if you have:
> >
> > class A : public B
> > {
> > };
> >
> > where class "B" has all sorts of interesting methods, the debug info will 
> > often look like:
> >
> > class B; // Forward declaration for class B
> >
> > class A : public B
> > {
> > };
> >
> > When this happens, we must make class A in a clang::ASTContext in 
> > DWARFASTParserClang and if "B" is a forward declaration, we can't leave it 
> > as a forward declaration or clang will assert and kill the debugger, so 
> > currently we just say "oh well, the compiler gave us lame debug info, and 
> > clang will crash if we don't fix this, so I am going to pretend we have a 
> > definition for class B and it contains nothing".
> >
> > Why not lookup the definition of B in the debug info at this point rather 
> > than making a stub/empty definition? (& if there is none, then, yes, I 
> > suppose an empty definition of B is as good as anything, maybe - it's going 
> > to produce some weird results, maybe)
> 
> LLDB creates types using only the debug info from the currently shared 
> library and we don't take a copy of a type from another shared library when 
> creating the types for a given shared library. Why? LLDB has a global 
> repository of modules (the class that represents an executable or shared 
> library in LLDB). If Xcode, or any other IDE that can debug more that one 
> thing at a time has two targets: "a.out" and "b.out", they share all of the 
> shared library modules so that if debug info has already been parsed in the 
> target for "a.out" for the shared library "liba.so" (or any other shared 
> library), then the "b.out" target has the debug info already loaded for 
> "liba.so" because "a.out" already loaded that module (LLDB runs in the same 
> address space as our IDE). This means that all debug info in LLDB currently 
> creates types using only the info in the current shared library. When we 
> debug "a.out" again, we might have recompiled "liba.so", but not "libb.so" 
> and when we debug again, we don't need to reload the debug info for "libb.so" 
> if it hasn't changed, we just reload "liba.so" and its debug info. When we 
> rerun a target (run a.out again), we don't need to spend any time reloading 
> any shared libraries that haven't changed since they are still in our global 
> shared library cache. So to keep this global library cache clean, we don't 
> allow types from another shared library (libb.so) to be loaded into another 
> (liba.so), otherwise we wouldn't be able to reap the benefits of our shared 
> library cache as we would always need to reload debug info every time we run.
> 
> Ah, right - I do remember you describing this to me before. Sorry I forgot.
> 
> Wouldn't it be sufficient to just copy the definition when needed? If the 
> type changes in an incompatible way in a dependent library, the user is up a 
> creek already, aren't they? (eg: libb.so is rebuilt with a new, incompatible 
> version of some type that liba.so uses, but liba.so is not rebuilt) Perhaps 
> you wouldn't be responsible for rebuilding the liba.so cache until it's 
> actually recompiled. Maybe?
>  

The fix to LLDB I want to do is to complete the type when we need to for base 
classes, but mark it with metadata. When we run expressions we create a new 
clang::ASTContext for each expression, and copy types over into it. The 
ASTImporter can be taught to look for the metadata on the class that says "I 
completed this class because I had to", and when copying it, we would grab the 
right type from the current version of libb.so. This keeps everyone happy: 
modules get their types with some classes completed but marked, and the 
expressions get the best version available in their AST contexts where if a 
complete version of the type is available we find it and copy it in place of 
the completed but incomplete version from the module AST.


> LLDB does have the ability, when displaying types, to grab types from the 
> best source (other shared libraries), we just don't transplant types in the 
> LLDB shared library objects (lldb_private::Module) versions of the types. We 
> do currently assume that all classes that aren't pointers or references (or 
> other types that can legally have forward declarations of structs or classes) 
> are complete in our current model.
> 
> There are modifications we can do to LLDB to deal with the partial debug info 
> and possible lack thereof when the debug info 

Re: [lldb-dev] [BUG] Many lookup failures

[David Blaikie via lldb-dev]

On Mon, Nov 30, 2015 at 2:42 PM, Greg Clayton  wrote:

> >
> > This will print out the complete class definition that we have for
> "CG::Node" including ivars and methods. You should be able to see the
> inheritance structure and you might need to also dump the type info for
> each inherited class.
> >
> > Compilers have been trying to not output a bunch of debug info and in
> the process they started to omit class info for base classes. So if you
> have:
> >
> > class A : public B
> > {
> > };
> >
> > where class "B" has all sorts of interesting methods, the debug info
> will often look like:
> >
> > class B; // Forward declaration for class B
> >
> > class A : public B
> > {
> > };
> >
> > When this happens, we must make class A in a clang::ASTContext in
> DWARFASTParserClang and if "B" is a forward declaration, we can't leave it
> as a forward declaration or clang will assert and kill the debugger, so
> currently we just say "oh well, the compiler gave us lame debug info, and
> clang will crash if we don't fix this, so I am going to pretend we have a
> definition for class B and it contains nothing".
> >
> > Why not lookup the definition of B in the debug info at this point
> rather than making a stub/empty definition? (& if there is none, then, yes,
> I suppose an empty definition of B is as good as anything, maybe - it's
> going to produce some weird results, maybe)
>
> LLDB creates types using only the debug info from the currently shared
> library and we don't take a copy of a type from another shared library when
> creating the types for a given shared library. Why? LLDB has a global
> repository of modules (the class that represents an executable or shared
> library in LLDB). If Xcode, or any other IDE that can debug more that one
> thing at a time has two targets: "a.out" and "b.out", they share all of the
> shared library modules so that if debug info has already been parsed in the
> target for "a.out" for the shared library "liba.so" (or any other shared
> library), then the "b.out" target has the debug info already loaded for
> "liba.so" because "a.out" already loaded that module (LLDB runs in the same
> address space as our IDE). This means that all debug info in LLDB currently
> creates types using only the info in the current shared library. When we
> debug "a.out" again, we might have recompiled "liba.so", but not "libb.so"
> and when we debug again, we don't need to reload the debug info for
> "libb.so" if it hasn't changed, we just reload "liba.so" and its debug
> info. When we rerun a target (run a.out again), we don't need to spend any
> time reloading any shared libraries that haven't changed since they are
> still in our global shared library cache. So to keep this global library
> cache clean, we don't allow types from another shared library (libb.so) to
> be loaded into another (liba.so), otherwise we wouldn't be able to reap the
> benefits of our shared library cache as we would always need to reload
> debug info every time we run.
>

Ah, right - I do remember you describing this to me before. Sorry I forgot.

Wouldn't it be sufficient to just copy the definition when needed? If the
type changes in an incompatible way in a dependent library, the user is up
a creek already, aren't they? (eg: libb.so is rebuilt with a new,
incompatible version of some type that liba.so uses, but liba.so is not
rebuilt) Perhaps you wouldn't be responsible for rebuilding the liba.so
cache until it's actually recompiled. Maybe?


> LLDB does have the ability, when displaying types, to grab types from the
> best source (other shared libraries), we just don't transplant types in the
> LLDB shared library objects (lldb_private::Module) versions of the types.
> We do currently assume that all classes that aren't pointers or references
> (or other types that can legally have forward declarations of structs or
> classes) are complete in our current model.
>
> There are modifications we can do to LLDB to deal with the partial debug
> info and possible lack thereof when the debug info for other shared
> libraries are not present, but we haven't done this yet in LLDB.
>
> >
> > I really don't like that the compiler thinks this is OK to do, but that
> is the reality and we have to deal with it.
> >
> > GCC's been doing it for a while longer than Clang & it represents a
> substantial space savings in debug info size - it'd be hard to explain to
> users why Clang's debug info is so much (20% or more) larger than GCC's
> when GCC's contains all the information required and GDB gives a good user
> experience with that information and LLDB does not.
>
> LLDB currently recreates types in a clang::ASTContext and this imposes
> much stricter rules on how we represent types which is one of the
> weaknesses of the LLDB approach to type representation as the clang
> codebase often asserts when it is not happy with how things are represented.


Sure, but it seems like it's the cache that's the real 

Re: [lldb-dev] [BUG] Many lookup failures

[David Blaikie via lldb-dev]

On Mon, Nov 30, 2015 at 3:29 PM, Greg Clayton  wrote:

>
> > On Nov 30, 2015, at 2:54 PM, David Blaikie  wrote:
> >
> >
> >
> > On Mon, Nov 30, 2015 at 2:42 PM, Greg Clayton 
> wrote:
> > >
> > > This will print out the complete class definition that we have for
> "CG::Node" including ivars and methods. You should be able to see the
> inheritance structure and you might need to also dump the type info for
> each inherited class.
> > >
> > > Compilers have been trying to not output a bunch of debug info and in
> the process they started to omit class info for base classes. So if you
> have:
> > >
> > > class A : public B
> > > {
> > > };
> > >
> > > where class "B" has all sorts of interesting methods, the debug info
> will often look like:
> > >
> > > class B; // Forward declaration for class B
> > >
> > > class A : public B
> > > {
> > > };
> > >
> > > When this happens, we must make class A in a clang::ASTContext in
> DWARFASTParserClang and if "B" is a forward declaration, we can't leave it
> as a forward declaration or clang will assert and kill the debugger, so
> currently we just say "oh well, the compiler gave us lame debug info, and
> clang will crash if we don't fix this, so I am going to pretend we have a
> definition for class B and it contains nothing".
> > >
> > > Why not lookup the definition of B in the debug info at this point
> rather than making a stub/empty definition? (& if there is none, then, yes,
> I suppose an empty definition of B is as good as anything, maybe - it's
> going to produce some weird results, maybe)
> >
> > LLDB creates types using only the debug info from the currently shared
> library and we don't take a copy of a type from another shared library when
> creating the types for a given shared library. Why? LLDB has a global
> repository of modules (the class that represents an executable or shared
> library in LLDB). If Xcode, or any other IDE that can debug more that one
> thing at a time has two targets: "a.out" and "b.out", they share all of the
> shared library modules so that if debug info has already been parsed in the
> target for "a.out" for the shared library "liba.so" (or any other shared
> library), then the "b.out" target has the debug info already loaded for
> "liba.so" because "a.out" already loaded that module (LLDB runs in the same
> address space as our IDE). This means that all debug info in LLDB currently
> creates types using only the info in the current shared library. When we
> debug "a.out" again, we might have recompiled "liba.so", but not "libb.so"
> and when we debug again, we don't need to reload the debug info for
> "libb.so" if it hasn't changed, we just reload "liba.so" and its debug
> info. When we rerun a target (run a.out again), we don't need to spend any
> time reloading any shared libraries that haven't changed since they are
> still in our global shared library cache. So to keep this global library
> cache clean, we don't allow types from another shared library (libb.so) to
> be loaded into another (liba.so), otherwise we wouldn't be able to reap the
> benefits of our shared library cache as we would always need to reload
> debug info every time we run.
> >
> > Ah, right - I do remember you describing this to me before. Sorry I
> forgot.
> >
> > Wouldn't it be sufficient to just copy the definition when needed? If
> the type changes in an incompatible way in a dependent library, the user is
> up a creek already, aren't they? (eg: libb.so is rebuilt with a new,
> incompatible version of some type that liba.so uses, but liba.so is not
> rebuilt) Perhaps you wouldn't be responsible for rebuilding the liba.so
> cache until it's actually recompiled. Maybe?
> >
>
> The fix to LLDB I want to do is to complete the type when we need to for
> base classes, but mark it with metadata. When we run expressions we create
> a new clang::ASTContext for each expression, and copy types over into it.
> The ASTImporter can be taught to look for the metadata on the class that
> says "I completed this class because I had to", and when copying it, we
> would grab the right type from the current version of libb.so. This keeps
> everyone happy: modules get their types with some classes completed but
> marked, and the expressions get the best version available in their AST
> contexts where if a complete version of the type is available we find it
> and copy it in place of the completed but incomplete version from the
> module AST.
>
>
> > LLDB does have the ability, when displaying types, to grab types from
> the best source (other shared libraries), we just don't transplant types in
> the LLDB shared library objects (lldb_private::Module) versions of the
> types. We do currently assume that all classes that aren't pointers or
> references (or other types that can legally have forward declarations of
> structs or classes) are complete in our current model.
> >
> > There are modifications we can do 

[lldb-dev] [Bug 25194] LLDB-Server Assertion raised when single stepping on MIPS

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25194

Sagar  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||sagar.tha...@imgtec.com
 Resolution|--- |FIXED

--- Comment #1 from Sagar  ---
Fixed by commit rL254379.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 24717] MiBreakTestCase.test_lldbmi_break_insert_function_pending is marked expectedFlakeyLinux, but still fails

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=24717

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from lab...@google.com ---
Seems to be passing reliably now. I have enabled the test again.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] reply: reply： lldb debug jit-compiled code with llvm on windows

[Tamas Berghammer via lldb-dev]

On Mon, Nov 30, 2015 at 10:18 AM haifeng_q  wrote:

> Question 1:
> On the windows, I use the code implements a function (see
> debug_target.cpp) of JIT (see debug_target_process.cpp), but when
> generating debug information, no production .symtab section for information
> that leads LLDB get JIT debugging information .symtab failure , and then
> set a breakpoint to fail.
>  LLDB command: lldb_result.txt
>  JIT compilation results: debug_target.ll
>
>  Question 2:
>  How JIT debugging supported on Linux?
>

I theory when a new function is JIT-ed then __jit_debug_register_code
function is called where LLDB have a breakpoint set. When that breakpoint
is hit then LLDB reads the JIT-ed elf file based on the information in
__it_debug_descriptor
and processes all debug info in it.

In practice when I last tried JIT debugging with lldb and lli (few weeks
ago) it get the notification for the new JIT-ed elf file but it processed
only the eh_frame from it even though symtab and full debug info was also
provided. Most likely there is some issue around the JIT breakpoint
handling or around the elf file parsing code in LLDB what needs
some investigation.

>
> thanks!
>
> -- The original message --
> *From:* "Zachary Turner";;
> *Data:* 2015年11月21日 AM 0:10
> *Receive:* "Tamas Berghammer"; " "<
> haifen...@foxmail.com>; "lldb-dev";
> *Title:* Re: [lldb-dev] reply： lldb debug jit-compiled code with llvm on
> windows
>
> Can you also try clang-cl and see if it works?
>
> On Fri, Nov 20, 2015 at 3:02 AM Tamas Berghammer via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I don't know how JIT debugging should work on WIndows with MSVC but I
>> don't think LLDB support it in any way. What I wrote should be true on
>> Linux (and on some related) systems. You might be able to get the same
>> results on Windows if you use lli (LLVM based JIT runner) but I have no
>> knowledge if it will work or not.
>>
>> On Fri, Nov 20, 2015 at 8:56 AM haifeng_q  wrote:
>>
>>> My analysis of the code, the reasons are:
>>>
>>> Since the debugging process is MSVC compiler, there is no DWARF debugging
>>> information. So lldb get __jit_debug_register_code and
>>> __it_debug_descriptor symbol debugging process fails, and
>>> __jit_debug_register_code not support MSVC.
>>> I do not know whether correct?
>>>
>>> -- original message--
>>> *From:*"Tamas Berghammer";tbergham...@google.com;
>>> Date*:*2015年11月19日 PM 8:37
>>> *receive:* " "; "lldb-dev"<
>>> lldb-dev@lists.llvm.org>;
>>> *Subject:* Re: [lldb-dev] lldb debug jit-compiled code with llvm on
>>> windows
>>>
>>> In theory you don't have to do anything special to debug some JIT-ed
>>> code as everything should just work (based on the gdb jit interface). In
>>> practice I tried it out a few days ago and it wasn't working at all even in
>>> the case when the application is launched under LLDB (not with attach).
>>> LLDB was understanding the eh_frame for the JIT-ed code but didn't found
>>> the debug info for unknown reason. We should investigate it and try to fix
>>> it sometime. We (lldb for android developers) plan to do it sometime but if
>>> you are interested in it then please feel free to take a look and let us
>>> know if you have any question.
>>>
>>> Tamas
>>>
>>> On Thu, Nov 19, 2015 at 8:40 AM haifeng_q via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
 hi,
 process A generate function Func1 code with llvm jit compiler, and calls
 Func1. modeled on "Kaleidoscope: Adding Debug Information" add debug
 information. how to use LLDB to attach process A to debug this function
 , add a breakpoint in the function?

 thanks!
 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

>>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev