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 break
https://llvm.org/bugs/show_bug.cgi?id=24717
lab...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 d
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
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 sa
"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 w
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 t
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
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:
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 wro
> On Nov 30, 2015, at 1:57 PM, Eric Christopher wrote:
>
>
>
> On Mon, 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.
>
>
> Greg cannot be more wrong here. There are some l
>
> 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
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.
> 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
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 met
> 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.
>
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 i
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
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 w
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'
https://llvm.org/bugs/show_bug.cgi?id=25194
Sagar changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
21 matches
Mail list logo
