On Tue, Dec 1, 2015 at 11:29 AM, Greg Clayton wrote:
> So one other issue with removing debug info from the current binary for
> base classes that are virtual: if the definition for the base class changes
> in libb.so, but liba.so was linked against an older version of class B from
> libb.so, lik
So one other issue with removing debug info from the current binary for base
classes that are virtual: if the definition for the base class changes in
libb.so, but liba.so was linked against an older version of class B from
libb.so, like for example:
class A : public B
{
int m_a;
};
If A w
> On 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 h
On Tue, Dec 1, 2015 at 2:11 AM David Blaikie via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> 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
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'
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 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 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 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 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.
>
> 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 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
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
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 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 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
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 nam
17 matches
Mail list logo
