Re: [lldb-dev] [BUG?] Confusion between translation units?
Greg Clayton wrote:
> Not really. If you can send me a concrete example of something that isn't
> working, it might help.
Reporting progress.
1. `im loo -t` only ever finds one "best match", and the plist seems
to have no effect on it.
2. The plist parsing code does get executed. I checked with the
debugger. I also checked symlink versus non-symlinked paths in the
plist, which I'd missed last time. dwarfdump does not seem to read it,
and `im loo` says nothing different, so I have no idea if anything
really got remapped.
3. I managed to catch this "unstable" case: you try something, it
prints a huge error, you try something else in a different frame with
the same type, it prints fine, you come back to the original thing and
there's a smaller error.
frame #0: 0x000101c3ce8c libmwcgir_vm_rt.dylib`(anonymous
namespace)::CgJITMemManager::endFunctionBody(this=0x00010e8637b0,
F=0x00010a62ccc0, FunctionStart="�?^\n\x01",
FunctionEnd="...")
+ 28 at CgJITMemoryManager.cpp:437
434(void)FunctionStart;
435(void)FunctionEnd;
436
-> 437assert(FunctionEnd > FunctionStart);
438assert(FunctionStart == (uint8_T *)(CurBlock+1) &&
439 "Mismatched function start/end!");
440
(lldb) p F
error: field 'BasicBlocks' declared with incompatible types in
different translation units ('BasicBlockListType' (aka
'llvm::iplist
>') vs. 'BasicBlockListType' (aka 'llvm::iplist >'))
error: field 'ArgumentList' declared with incompatible types in
different translation units ('ArgumentListType' (aka
'llvm::iplist >')
vs. 'ArgumentListType' (aka 'llvm::iplist >'))
error: field 'BasicBlocks' declared with incompatible types in
different translation units ('BasicBlockListType' (aka
'llvm::iplist
>') vs. 'BasicBlockListType' (aka 'llvm::iplist >'))
error: field 'Context' declared with incompatible types in different
translation units ('llvm::LLVMContext &' vs. 'llvm::LLVMContext &')
error: field 'GlobalList' declared with incompatible types in
different translation units ('GlobalListType' (aka
'llvm::iplist >') vs. 'GlobalListType' (aka
'llvm::iplist >'))
error: field 'FunctionList' declared with incompatible types in
different translation units ('FunctionListType' (aka
'llvm::iplist >')
vs. 'FunctionListType' (aka 'llvm::iplist >'))
error: field 'AliasList' declared with incompatible types in different
translation units ('AliasListType' (aka
'llvm::iplist
>') vs. 'AliasListType' (aka 'llvm::iplist >'))
error: field 'NamedMDList' declared with incompatible types in
different translation units ('NamedMDListType' (aka
'llvm::ilist') vs. 'NamedMDListType' (aka
'llvm::ilist'))
error: field 'GlobalScopeAsm' declared with incompatible types in
different translation units ('string' (aka
'std::__1::basic_string,
std::__1::allocator >') vs. 'string' (aka
'std::__1::basic_string,
std::__1::allocator >'))
error: field 'ComdatSymTab' declared with incompatible types in
different translation units ('ComdatSymTabType' (aka
'llvm::StringMap') vs.
'ComdatSymTabType' (aka 'llvm::StringMap'))
error: field 'ModuleID' declared with incompatible types in different
translation units ('string' (aka 'std::__1::basic_string, std::__1::allocator >') vs.
'string' (aka 'std::__1::basic_string, std::__1::allocator >'))
error: field 'TargetTriple' declared with incompatible types in
different translation units ('string' (aka
'std::__1::basic_string,
std::__1::allocator >') vs. 'string' (aka
'std::__1::basic_string,
std::__1::allocator >'))
error: field 'DataLayoutStr' declared with incompatible types in
different translation units ('string' (aka
'std::__1::basic_string,
std::__1::allocator >') vs. 'string' (aka
'std::__1::basic_string,
std::__1::allocator >'))
error: field 'Parent' declared with incompatible types in different
translation units ('llvm::Module *' vs. 'llvm::Module *')
error: field 'Parent' declared with incompatible types in different
translation units ('l
Re: [lldb-dev] [BUG?] Confusion between translation units?
Greg Clayton wrote: > Be sure to use "frame variable" more as it will never run into these type > importation problems when you need to view a variable or members of a > variable. > > It would be interesting to see the output of "frame variable" from frame 0 > and frame 4 and see if they differ at all. `fr va` seems to fix the immediate problem, thanks! I'll let you know if I run into issues with it. We really should fix the expression parser, no? Why is it behaving strangely? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] --no-stdin mode kicks in without warning (?)
Hi, I never do --no-stdin, because the program I'm debugging often takes input. If I debug in one of the normal sessions for an extended period of time, 'continue' returns the (lldb) prompt immediately, which claims that the program is running (it's actually waiting for input). At this point, I have no choice but to start over, because there's no way to go from the --no-stdin mode to the normal mode (?). I'm not able to give reproduction steps, but I think it has to do with the program being multi-threaded? Ram ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [BUG] Many lookup failures
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
Re: [lldb-dev] [BUG] Many lookup failures
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] [BUG] Many lookup failures
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. > 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? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Do we have the equivalent of `layout asm`?
Hi, gdb has a `layout asm` which is very useful while debugging assembly. Do we have something like that in lldb? Thanks. Ram ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Why is function not present in target?
Hi, This has been the source of much frustration, but I can't quite figure out why my toString() member function is not present in the target, according to lldb. The other functions in the compile unit are used and present, so the linker couldn't have eliminated the compile unit. Nor could the function have been inlined, because it is not used anywhere (it's written solely for the purpose of being used within lldb), so there's nowhere to inline into. So where is my function? And why isn't lldb picking it up? Thanks. Ram ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Why is function not present in target?
Hi, Pavel Labath wrote: > > a have couple of question to better understand the situation: > - what is the system you are trying this out on (OS, arch, ...)? > macOS, x86_64. > - are you using any funny compiler options that you think we should > know about ? (e.g. if you're using -ffunction-sections > -Wl,--gc-sections, then the function could have been removed even if > the parts of the compile unit stay) > Linker invocation: Linking Shared Object ../../bin/maci64/libmwcgir_polly.dylib xcrun -sdk macosx10.11 clang++ -arch x86_64 -dynamiclib -single_module -install_name @rpath/libmwcgir_polly.dylib -Wl,-mark_dead_strippable_dylib -arch x86_64 -mmacosx-version-min=10.9 -stdlib=libc++ -Wl,-dead_strip -Wl,-dead_strip_dylibs -stdlib=libc++ -o ../../bin/maci64/libmwcgir_polly.dylib ../../derived/maci64/obj/src/cgir_polly/Analysis/MemoryAccess.o ../../derived/maci64/obj/src/cgir_polly/Analysis/SCOP.o ../../derived/maci64/obj/src/cgir_polly/Analysis/SCOPExtraction.o ../../derived/maci64/obj/src/cgir_polly/Analysis/SCOPStmt.o ../../derived/maci64/obj/src/cgir_polly/CodeGen/IRGeneration.o ../../derived/maci64/obj/src/cgir_polly/IslWrap/Isl.o ../../derived/maci64/obj/src/cgir_polly/Transform/Polly.o ../../derived/maci64/obj/src/cgir_polly/Transform/PollyImpl.o ../../derived/maci64/obj/src/cgir_polly/Util/PollyPrinter.o ../../derived/maci64/obj/src/cgir_polly/modver.o -L../../bin/maci64 -L../../bin/maci64 -lmwfoundation_usm -lmwcg_ir -lmwcgir_support -lmwcgir_cgel -lut -lmwfl -L../../bin/maci64 -lboost_system -L../../bin/maci64 -lmwcpp11compat -L//mathworks/hub/3rdparty/R2017b/2334121/maci64/isl/lib -lisl -L//mathworks/hub/3rdparty/R2017b/2309377/maci64/jsoncpp/lib -ljsoncpp -L//mathworks/hub/3rdparty/R2017a/2105192/maci64/python2/lib -lpython2.7 -Wl,-rpath,@loader_path -Wl,-rpath,@loader_path/. -Wl,-rpath,@loader_path/../../sys/os/maci64 xcrun -sdk macosx10.11 clang++ -arch x86_64 -c pkgtest/tMatrixAssign.cpp -o ../../derived/maci64/obj/src/cgir_polly/pkgtest/tMatrixAssign.o -MMD -MF ../../derived/maci64/obj/src/cgir_polly/pkgtest/tMatrixAssign.d -MP -MT ../../derived/maci64/obj/src/cgir_polly/pkgtest/tMatrixAssign.o -Iexport/include -I. -I../../src/include -I../../derived/maci64/src/include -I../include -I../../include -I../../derived/maci64/src/cgir_polly/include -I../../derived/maci64/src/cgir_polly/ -isystem//mathworks/hub/3rdparty/R2017a/1971079/maci64/boost/include -isystem//mathworks/hub/3rdparty/R2017a/1946655/maci64/cpp11compat/include -isystem//mathworks/hub/3rdparty/R2017b/2334121/maci64/isl/include -isystem//mathworks/hub/3rdparty/R2017b/2309377/maci64/jsoncpp/include -isystem//mathworks/hub/3rdparty/R2017a/2105192/maci64/python2/include/python2.7 -isystem//mathworks/hub/3rdparty/R2017a/2101198/maci64/gmock/include/gmock -isystem//mathworks/hub/3rdparty/R2017a/2101198/maci64/gmock/include/gtest -mmacosx-version-min=10.9 -DMODULE_VERSION_SYMBOL=libmwcgir_polly_version -DMODULE_DATE_SYMBOL=libmwcgir_polly_build_date -Dmw_test_main=main -DBOOST_CB_DISABLE_DEBUG -DBOOST_THREAD_FUTURE=unique_future -DBOOST_SPIRIT_THREADSAFE -DPHOENIX_THREADSAFE -DBOOST_SIGNALS_NO_DEPRECATION_WARNING -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS -DBOOST_MPL_LIMIT_VECTOR_SIZE=30 -DBOOST_MPL_LIMIT_MAP_SIZE=30 -DNEEDS_BOOST_UNIQUE_PTR=1 -DBUILDING_CGIR_POLLY -DGTEST_MW_USE_MW_NOT_EQUALS=1 -DGTEST_LINKED_AS_SHARED_LIBRARY=1 -DBUILDING_PKGTEST -O2 -stdlib=libc++ -pipe -D_REENTRANT -std=c++11 -g -DNDEBUG -Wextra -Wno-unused-parameter -Wno-ignored-qualifiers -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Woverloaded-virtual -Wnon-virtual-dtor -Wno-unused -Wno-inconsistent-missing-override -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -std=c++11 -stdlib=libc++ -ftemplate-depth-1024 -Werror So yes, there's -Wl,-mark_dead_strippable_dylib + -Wl,-dead_strip + -Wl,-dead_strip_dylibs. > - how exactly is your function declared? (e.g. if it's declared as > inline, or a template and unused then the compiler might not bother > emitting it) > It's not inline or a template. It's just a vanilla member function. > - could you verify (e.g. by running "objdump -t") that your function > is indeed present in the resulting binary? > macOS, so: $ nm -a libmwcgir_polly.dylib | grep toString 50b0 T __ZNK2CG8analysis4SCOP8toStringEv 00026f60 T __ZNK2CG8analysis8SCOPStmt8toStringEv Does this mean that they're present? Ram ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Why is function not present in target?
I got around the problem using attribute used. Ram On Fri, Feb 10, 2017 at 9:02 AM Ramkumar Ramachandra wrote: > Hi, > > Pavel Labath wrote: > > a have couple of question to better understand the situation: > - what is the system you are trying this out on (OS, arch, ...)? > > > macOS, x86_64. > > > - are you using any funny compiler options that you think we should > know about ? (e.g. if you're using -ffunction-sections > -Wl,--gc-sections, then the function could have been removed even if > the parts of the compile unit stay) > > > Linker invocation: > > Linking Shared Object ../../bin/maci64/libmwcgir_polly.dylib > xcrun -sdk macosx10.11 clang++ -arch x86_64 -dynamiclib -single_module > -install_name @rpath/libmwcgir_polly.dylib -Wl,-mark_dead_strippable_dylib > -arch x86_64 -mmacosx-version-min=10.9 -stdlib=libc++ -Wl,-dead_strip > -Wl,-dead_strip_dylibs -stdlib=libc++ -o > ../../bin/maci64/libmwcgir_polly.dylib > ../../derived/maci64/obj/src/cgir_polly/Analysis/MemoryAccess.o > ../../derived/maci64/obj/src/cgir_polly/Analysis/SCOP.o > ../../derived/maci64/obj/src/cgir_polly/Analysis/SCOPExtraction.o > ../../derived/maci64/obj/src/cgir_polly/Analysis/SCOPStmt.o > ../../derived/maci64/obj/src/cgir_polly/CodeGen/IRGeneration.o > ../../derived/maci64/obj/src/cgir_polly/IslWrap/Isl.o > ../../derived/maci64/obj/src/cgir_polly/Transform/Polly.o > ../../derived/maci64/obj/src/cgir_polly/Transform/PollyImpl.o > ../../derived/maci64/obj/src/cgir_polly/Util/PollyPrinter.o > ../../derived/maci64/obj/src/cgir_polly/modver.o -L../../bin/maci64 > -L../../bin/maci64 -lmwfoundation_usm -lmwcg_ir -lmwcgir_support > -lmwcgir_cgel -lut -lmwfl -L../../bin/maci64 -lboost_system > -L../../bin/maci64 -lmwcpp11compat > -L//mathworks/hub/3rdparty/R2017b/2334121/maci64/isl/lib -lisl > -L//mathworks/hub/3rdparty/R2017b/2309377/maci64/jsoncpp/lib -ljsoncpp > -L//mathworks/hub/3rdparty/R2017a/2105192/maci64/python2/lib -lpython2.7 > -Wl,-rpath,@loader_path -Wl,-rpath,@loader_path/. > -Wl,-rpath,@loader_path/../../sys/os/maci64 > xcrun -sdk macosx10.11 clang++ -arch x86_64 -c pkgtest/tMatrixAssign.cpp > -o ../../derived/maci64/obj/src/cgir_polly/pkgtest/tMatrixAssign.o -MMD -MF > ../../derived/maci64/obj/src/cgir_polly/pkgtest/tMatrixAssign.d -MP -MT > ../../derived/maci64/obj/src/cgir_polly/pkgtest/tMatrixAssign.o > -Iexport/include -I. -I../../src/include > -I../../derived/maci64/src/include -I../include -I../../include > -I../../derived/maci64/src/cgir_polly/include > -I../../derived/maci64/src/cgir_polly/ > -isystem//mathworks/hub/3rdparty/R2017a/1971079/maci64/boost/include > -isystem//mathworks/hub/3rdparty/R2017a/1946655/maci64/cpp11compat/include > -isystem//mathworks/hub/3rdparty/R2017b/2334121/maci64/isl/include > -isystem//mathworks/hub/3rdparty/R2017b/2309377/maci64/jsoncpp/include > -isystem//mathworks/hub/3rdparty/R2017a/2105192/maci64/python2/include/python2.7 > -isystem//mathworks/hub/3rdparty/R2017a/2101198/maci64/gmock/include/gmock > -isystem//mathworks/hub/3rdparty/R2017a/2101198/maci64/gmock/include/gtest > -mmacosx-version-min=10.9 > -DMODULE_VERSION_SYMBOL=libmwcgir_polly_version > -DMODULE_DATE_SYMBOL=libmwcgir_polly_build_date -Dmw_test_main=main > -DBOOST_CB_DISABLE_DEBUG -DBOOST_THREAD_FUTURE=unique_future > -DBOOST_SPIRIT_THREADSAFE -DPHOENIX_THREADSAFE > -DBOOST_SIGNALS_NO_DEPRECATION_WARNING > -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS -DBOOST_MPL_LIMIT_VECTOR_SIZE=30 > -DBOOST_MPL_LIMIT_MAP_SIZE=30 -DNEEDS_BOOST_UNIQUE_PTR=1 > -DBUILDING_CGIR_POLLY -DGTEST_MW_USE_MW_NOT_EQUALS=1 > -DGTEST_LINKED_AS_SHARED_LIBRARY=1 -DBUILDING_PKGTEST -O2 -stdlib=libc++ > -pipe -D_REENTRANT -std=c++11 -g -DNDEBUG -Wextra -Wno-unused-parameter > -Wno-ignored-qualifiers -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual > -Woverloaded-virtual -Wnon-virtual-dtor -Wno-unused > -Wno-inconsistent-missing-override -Wno-parentheses-equality > -Wno-self-assign -Wno-tautological-compare -std=c++11 -stdlib=libc++ > -ftemplate-depth-1024 -Werror > > So yes, there's -Wl,-mark_dead_strippable_dylib + -Wl,-dead_strip + > -Wl,-dead_strip_dylibs. > > > - how exactly is your function declared? (e.g. if it's declared as > inline, or a template and unused then the compiler might not bother > emitting it) > > > It's not inline or a template. It's just a vanilla member function. > > > - could you verify (e.g. by running "objdump -t") that your function > is indeed present in the resulting binary? > > > macOS, so: > > $ nm -a libmwcgir_polly.dylib | grep toString > 50b0 T __ZNK2CG8analysis4SCOP8toStringEv > 00026f60 T __ZNK2CG8analysis8SCOPStmt8toStringEv > > Does this mean that they're present? > > Ram > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] EvaluateExpression has trailing error
Hi,
My script is simple enough:
import lldb
def pp(debugger, command, result, internal_dict):
target = debugger.GetSelectedTarget()
process = target.GetProcess()
thread = process.GetSelectedThread()
frame = thread.GetSelectedFrame()
res = frame.EvaluateExpression("%s->dump()" % command)
print >>result, res
def __lldb_init_module(debugger, internal_dict):
debugger.HandleCommand('command script add -f llvm_pp.pp pp')
print "Command pp installed"
However, when I execute it:
(lldb) pp Ty
Fn(Void -> Int)*
=
When I use res.GetSummary() in place of res, I get "None" instead of
the error. What is this trailing data anyway, and how do I get rid of
it?
Thanks.
Ram
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] EvaluateExpression has trailing error
Hm, that doesn't seem to be it.
(lldb) pp R
var ~UnType
typename = ""
() =
On Mon, Aug 24, 2015 at 12:51 PM, Greg Clayton wrote:
> The type name for "Ty" might have a newline in it. Try this:
>
>
>res = frame.EvaluateExpression("%s->dump()" % command)
>print >>result, 'typename = "%s"' % (res.GetType().GetName())
>print >>result, res
>
> See if the double quote is on the next line.
>
>> On Aug 22, 2015, at 11:58 AM, Ramkumar Ramachandra via lldb-dev
>> wrote:
>>
>> Hi,
>>
>> My script is simple enough:
>>
>> import lldb
>>
>> def pp(debugger, command, result, internal_dict):
>>target = debugger.GetSelectedTarget()
>>process = target.GetProcess()
>>thread = process.GetSelectedThread()
>>frame = thread.GetSelectedFrame()
>>res = frame.EvaluateExpression("%s->dump()" % command)
>>print >>result, res
>>
>> def __lldb_init_module(debugger, internal_dict):
>>debugger.HandleCommand('command script add -f llvm_pp.pp pp')
>>print "Command pp installed"
>>
>> However, when I execute it:
>>
>> (lldb) pp Ty
>> Fn(Void -> Int)*
>> =
>>
>> When I use res.GetSummary() in place of res, I get "None" instead of
>> the error. What is this trailing data anyway, and how do I get rid of
>> it?
>>
>> Thanks.
>>
>> Ram
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=e494ZqshU04UaasD49FjA8X8-41XrPe2DEAUCC4uIBA&m=hREFWCzPJ65eZn31OtjvanOAmZpkHcfxvRV-A7W-jcA&s=ZDMXskG0jb4bfdKZu5O9l2rpbV149UaUmFNvWw1LrRY&e=
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Get vtable info from the image
Hi, I believe there's now a: (gdb) info vtbl ... and I'm unable to find the equivalent of this in lldb. I usually do: (lldb) im look -r -v -s ... and look for the vtable info in the output, but it doesn't always seem to be there. What am I missing? Thanks. Ram ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Get vtable info from the image
Ha, turns out it's (lldb) im look -r -v -s "vtable for ..." We should document this in http://lldb.llvm.org/lldb-gdb.html On Tue, Sep 15, 2015 at 9:53 AM, Ramkumar Ramachandra wrote: > Hi, > > I believe there's now a: > > (gdb) info vtbl ... > > and I'm unable to find the equivalent of this in lldb. I usually do: > > (lldb) im look -r -v -s ... > > and look for the vtable info in the output, but it doesn't always seem > to be there. > > What am I missing? > > Thanks. > > Ram ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [BUG?] Confusion between translation units?
Hi,
At one point in the debugging session, I get this when I try to print
a particular value:
error: field '__r_' declared with incompatible types in different
translation units
('std::__1::__compressed_pair, std::__1::allocator >::__rep,
std::__1::allocator >' vs.
'std::__1::__compressed_pair, std::__1::allocator >::__rep,
std::__1::allocator >')
error: field '__r_' declared with incompatible types in different
translation units
('std::__1::__compressed_pair, std::__1::allocator >::__rep,
std::__1::allocator >' vs.
'std::__1::__compressed_pair, std::__1::allocator >::__rep,
std::__1::allocator >')
error: field '__r_' declared with incompatible types in different
translation units
('std::__1::__compressed_pair, std::__1::allocator >::__rep,
std::__1::allocator >' vs.
'std::__1::__compressed_pair, std::__1::allocator >::__rep,
std::__1::allocator >')
error: field '__r_' declared with incompatible types in different
translation units
('std::__1::__compressed_pair, std::__1::allocator >::__rep,
std::__1::allocator >' vs.
'std::__1::__compressed_pair, std::__1::allocator >::__rep,
std::__1::allocator >')
note: declared here with type
'std::__1::__compressed_pair, std::__1::allocator >::__rep,
std::__1::allocator >'
note: declared here with type
'std::__1::__compressed_pair, std::__1::allocator >::__rep,
std::__1::allocator >'
note: declared here with type
'std::__1::__compressed_pair, std::__1::allocator >::__rep,
std::__1::allocator >'
note: declared here with type
'std::__1::__compressed_pair, std::__1::allocator >::__rep,
std::__1::allocator >'
(which makes no sense at all; lhs and rhs are identical)
After that point, whatever I try to print returns this error.
What is going on?
Thanks.
Ram
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [BUG?] Confusion between translation units?
Thanks for an excellent explanation.
Unfortunately, -fno-limit-debug-info did not fix the problem; and that
I don't see the problem with a gcc/gdb setup.
So what I'm doing is forward-declaring LLVM IR entities (like `Value',
`Type', `Function'), so that multiple downstream modules don't include
those LLVM headers potentially double-including global statics. I'm
trying to look inside an llvm::Function * in the debugger now, and it
fails.
I'm going to try building LLVM itself with -fno-limit-debug-info now.
Let me know if there are other things I can try.
Thanks.
Ram
On Tue, Oct 13, 2015 at 6:26 PM, Greg Clayton wrote:
> In LLDB we create clang::ASTContext objects for the modules (executable and
> shared libraries), one for the target to contain the expression results, and
> one for each expression.
>
> When we evaluate an expression we might do something like:
>
> (lldb) expr a + b
>
> where "a" is from liba.so and "b" is from libb.so. We must copy types from
> the clang::ASTContext for each module, so we will copy the type of "a" into
> the expression clang::ASTContext and we will also copy type "b" from the
> clang::ASTContext from libb.so into the expression clang::ASTContext. Many
> times we the same types, but one has more information in it. Like lets say
> both "a" and "b" are type "foo". We can often end up with different
> definitions of "foo" in liba.so and libb.so and when we try to copy the
> types, we first copy "foo" from liba.so into the expression AST, and
> then we do the same with "b" from libb.so, but it notices that the types are
> the same level, so it tries to verify the types are the same. This often
> fails due to debug info being more complete in one of the shared libraries.
> One example is the compiler might omit the complete definition for a base
> class in libb.so where it has a complete definition for the base class in
> liba.so. When parsing types we must always give clang something it is happy
> with, so if we run into debug info that has a complete definition for
> "foo", but it inherits from class "C". So the definition for "C" in
> liba.so is:
>
> class C
> {
> public:
> C();
> ~C();
> int callme();
> };
>
> and "C" in "libb.so" is just a forward declaration:
>
> class C;
>
> But then int libb.so we must create a type for foo but we can't since C
> isn't complete, but we do anyway by just saying C looks like:
>
> class C
> {
> };
>
> So now we have two types that differ, and importing both foo types into
> the expression clang::ASTContext will fail. This happens a lot for C++
> template classes because of the haphazard way that compilers generate debug
> info for templates. It could be a bug in the type importer where the two
> types are actually the same, but the type importer thinks they are different,
> but often it is because the types actually do differ.
>
> One way to get around the compiler emitting forward declarations to base
> classes is to specify: -fno-limit-debug-info
>
> This will disable the debug info minimizing feature and make the compiler
> emit more complete debug info and it might fix your problem.
>
> Greg Clayton
>
>> On Oct 13, 2015, at 10:44 AM, Ramkumar Ramachandra via lldb-dev
>> wrote:
>>
>> Hi,
>>
>> At one point in the debugging session, I get this when I try to print
>> a particular value:
>>
>> error: field '__r_' declared with incompatible types in different
>> translation units
>> ('std::__1::__compressed_pair> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator >' vs.
>> 'std::__1::__compressed_pair> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator >')
>> error: field '__r_' declared with incompatible types in different
>> translation units
>> ('std::__1::__compressed_pair> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator >' vs.
>> 'std::__1::__compressed_pair> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator >')
>> error: field '__r_' declared with incompatible types in different
>> translation units
>> ('std::__1::__compressed_pair> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator >' vs.
>> 'std::__1::__compressed_pair> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator >&#
Re: [lldb-dev] [BUG?] Confusion between translation units?
Alright, let's try to fix the bug.
Let's work backward from the leaves: clang's ASTImporter.cpp:2979 and
AstImporter.cpp:3044. In the backtrace, what seems to be most relevant
is a call inside layoutRecordType, namely ClangASTSource.cpp:1709. The
codebase clearly shows efforts to emit "Please retry with
-fno-limit-debug-info", so I can infer that we intend to catch every
non-IsStructurallyEquivalent before it goes to clang, and emit a good
error message if best-effort fails. ClangASTContext.cpp is littered
with `omit_empty_base_classes`, so some machinery to handle forward
declarations properly is already in place.
Back to where we were debugging. GetCompleteDecl seems relevant, and
we aren't using its return value, so we have no way of telling if it's
a complete definition, right? Why am I guessing instead of
interactively debugging? Because the debugger is useless at this
stage, thanks to the same bug :)
I think the bug is just a matter of missing a corner case, but I could
be wrong. Let me know your thoughts.
Ram
On Wed, Oct 14, 2015 at 11:06 AM, Ramkumar Ramachandra
wrote:
> Thanks for an excellent explanation.
>
> Unfortunately, -fno-limit-debug-info did not fix the problem; and that
> I don't see the problem with a gcc/gdb setup.
>
> So what I'm doing is forward-declaring LLVM IR entities (like `Value',
> `Type', `Function'), so that multiple downstream modules don't include
> those LLVM headers potentially double-including global statics. I'm
> trying to look inside an llvm::Function * in the debugger now, and it
> fails.
>
> I'm going to try building LLVM itself with -fno-limit-debug-info now.
> Let me know if there are other things I can try.
>
> Thanks.
>
> Ram
>
> On Tue, Oct 13, 2015 at 6:26 PM, Greg Clayton wrote:
>> In LLDB we create clang::ASTContext objects for the modules (executable and
>> shared libraries), one for the target to contain the expression results, and
>> one for each expression.
>>
>> When we evaluate an expression we might do something like:
>>
>> (lldb) expr a + b
>>
>> where "a" is from liba.so and "b" is from libb.so. We must copy types from
>> the clang::ASTContext for each module, so we will copy the type of "a" into
>> the expression clang::ASTContext and we will also copy type "b" from the
>> clang::ASTContext from libb.so into the expression clang::ASTContext. Many
>> times we the same types, but one has more information in it. Like lets say
>> both "a" and "b" are type "foo". We can often end up with different
>> definitions of "foo" in liba.so and libb.so and when we try to copy the
>> types, we first copy "foo" from liba.so into the expression AST, and
>> then we do the same with "b" from libb.so, but it notices that the types are
>> the same level, so it tries to verify the types are the same. This often
>> fails due to debug info being more complete in one of the shared libraries.
>> One example is the compiler might omit the complete definition for a base
>> class in libb.so where it has a complete definition for the base class in
>> liba.so. When parsing types we must always give clang something it is happy
>> with, so if we run into debug info that has a complete definition for
>> "foo", but it inherits from class "C". So the definition for "C" in
>> liba.so is:
>>
>> class C
>> {
>> public:
>> C();
>> ~C();
>> int callme();
>> };
>>
>> and "C" in "libb.so" is just a forward declaration:
>>
>> class C;
>>
>> But then int libb.so we must create a type for foo but we can't since C
>> isn't complete, but we do anyway by just saying C looks like:
>>
>> class C
>> {
>> };
>>
>> So now we have two types that differ, and importing both foo types into
>> the expression clang::ASTContext will fail. This happens a lot for C++
>> template classes because of the haphazard way that compilers generate debug
>> info for templates. It could be a bug in the type importer where the two
>> types are actually the same, but the type importer thinks they are
>> different, but often it is because the types actually do differ.
>>
>> One way to get around the compiler emitting forward declarations to base
>> classes is to specify: -fno-limit-debug-info
>>
>> This will disable the debug info minimizing feature and make the compiler
>> emit more complete debug info and it might fix your problem.
>>
>> Gre
Re: [lldb-dev] [BUG?] Confusion between translation units?
Greg Clayton wrote: > Yes I have seen a bunch of problems like this on linux due to types being > incomplete in the debug info (my guess). But I would like to verify that the > manual DWARF indexing isn't to blame for this. We have great accelerator > tables that the clang makes for us that actually have all of the info we need > to find types and functions quickly, whereas all other platforms must run > SymbolFileDWARF::Index() to manually index the DWARF. I'm on OS X, so none of this applies? > I should be able to tell if you can send me an ELF file and say where you > were and wait wasn't showing up correctly (which variables) in an exact code > context (which file + line or exact line in a function). Then I can verify > that SymbolFileDWARF::Index() is correctly indexing things so that we can > find types and functions when we need them. I've been mulling over this problem: do you want to be able to run the Mach-O, or do you just want to inspect it? The transitive closure of the dependencies is atleast 30 .dylibs, and I can't take out that much IP. So what are we looking for exactly? Thanks. Ram ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [BUG] Regression: unprintable characters displayed
Hi, This does not happen with lldb-330.0.48, which ships with OS X, but happens with HEAD: frame #0: 0x000101c3ce8c libmwcgir_vm_rt.dylib`(anonymous namespace)::CgJITMemManager::endFunctionBody(this=0x00010a715610, F=0x00010a6da200, FunctionStart="�?^\n\x01", FunctionEnd="...") + 28 at CgJITMemoryManager.cpp:437 We can easily detect if the characters are printable or not , no? FunctionStart and FunctionEnd are uint8_t *. Ram ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [BUG?] Confusion between translation units?
[Quoting entire email for the benefit of everyone else]
On Tue, Oct 20, 2015 at 7:39 PM, Greg Clayton wrote:
> Ok, so try this on all of your dSYM files:
>
> 1 - load the dsym file into lldb:
>
> % xcrun lldb
> libmwcgir_vm_rt.dylib.dSYM/Contents/Resources/DWARF/libmwcgir_vm_rt.dylib
> (lldb) image lookup -t "iplist llvm::ilist_traits >"
> 2 matches found in
> /Volumes/work/gclayton/Downloads/libmwcgir_vm_rt.dylib.dSYM/Contents/Resources/DWARF/libmwcgir_vm_rt.dylib:
> id = {0x000211dc}, name = "iplist llvm::ilist_traits >", qualified =
> "llvm::iplist >",
> byte-size = 24, decl = ilist.h:313, clang_type = "class iplist : public
> llvm::ilist_traits {
> llvm::Function *Head;
> llvm::Function *getTail();
> const llvm::Function *getTail() const;
> void setTail(llvm::Function *) const;
> void CreateLazySentinel() const;
> static bool op_less(llvm::Function &, llvm::Function &);
> static bool op_equal(llvm::Function &, llvm::Function &);
> iplist(const llvm::iplist llvm::ilist_traits > &);
> void operator=(const llvm::iplist llvm::ilist_traits > &);
> iplist();
> ~iplist();
> iterator begin();
> const_iterator begin() const;
> iterator end();
> const_iterator end() const;
> reverse_iterator rbegin();
> const_reverse_iterator rbegin() const;
> reverse_iterator rend();
> const_reverse_iterator rend() const;
> size_type max_size() const;
> bool empty() const;
> reference front();
> const_reference front() const;
> reference back();
> const_reference back() const;
> void swap(llvm::iplist
> > &);
> iterator insert(iterator, llvm::Function *);
> iterator insertAfter(iterator, llvm::Function *);
> llvm::Function *remove(iterator &);
> llvm::Function *remove(const iterator &);
> iterator erase(iterator);
> void clearAndLeakNodesUnsafely();
> void transfer(iterator, llvm::iplist llvm::ilist_traits > &, iterator, iterator);
> size_type size() const;
> iterator erase(iterator, iterator);
> void clear();
> void push_front(llvm::Function *);
> void push_back(llvm::Function *);
> void pop_front();
> void pop_back();
> void splice(iterator, llvm::iplist llvm::ilist_traits > &);
> void splice(iterator, llvm::iplist llvm::ilist_traits > &, iterator);
> void splice(iterator, llvm::iplist llvm::ilist_traits > &, iterator, iterator);
> void erase(const llvm::Function &);
> void unique();
> void merge(llvm::iplist llvm::ilist_traits > &);
> void sort();
> }
> "
> id = {0x001a658a}, name = "iplist llvm::ilist_traits >", qualified =
> "llvm::iplist >",
> byte-size = 24, decl = ilist.h:313, clang_type = "class iplist : public
> llvm::ilist_traits {
> llvm::Function *Head;
> llvm::Function *getTail();
> const llvm::Function *getTail() const;
> void setTail(llvm::Function *) const;
> void CreateLazySentinel() const;
> static bool op_less(llvm::Function &, llvm::Function &);
> static bool op_equal(llvm::Function &, llvm::Function &);
> iplist(const llvm::iplist llvm::ilist_traits > &);
> void operator=(const llvm::iplist llvm::ilist_traits > &);
> iplist();
> ~iplist();
> iterator begin();
> const_iterator begin() const;
> iterator end();
> const_iterator end() const;
> reverse_iterator rbegin();
> const_reverse_iterator rbegin() const;
> reverse_iterator rend();
> const_reverse_iterator rend() const;
> size_type max_size() const;
> bool empty() const;
> reference front();
> const_reference front() const;
> reference back();
> const_reference back() const;
> void swap(llvm::iplist
> > &);
> iterator insert(iterator, llvm::Function *);
> iterator insertAfter(iterator, llvm::Function *);
> llvm::Function *remove(iterator &);
> llvm::Function *remove(const iterator &);
> iterator erase(iterator);
> void clearAndLeakNodesUnsafely();
> void transfer(iterator, llvm::iplist llvm::ilist_traits > &, iterator, iterator);
> size_type size() const;
> iterator erase(iterator, iterator);
> void clear();
> void push_front(llvm::Function *);
> void push_back(llvm::Function *);
> void pop_front();
> void pop_back();
> void splice(iterator, llvm::iplist llvm::ilist_traits > &);
> void splice(iterator, llvm::iplist llvm::ilist_traits > &, iterator);
> void splice(iterator, llvm::iplist llvm::ilist_traits > &, iterator, iterator);
> void erase(const llvm::Function &);
> void unique();
> void merge(llvm::iplist llvm::ilist_traits > &);
> void sort();
> }
> "
>
>
> Do the same thing for any other shared libraries that you have and compare
> the data in quotes of the 'clang_type = ""' and save the to a
> file. See if any of them differ from each other.
>
>
> What is interesting here is that we have two of the same copies of this type
> in the same file, this shouldn't happen
Re: [lldb-dev] [BUG?] Confusion between translation units?
On Tue, Oct 20, 2015 at 8:22 PM, Greg Clayton wrote: > Then try running and let me know what your results are! Hm, there seems to be something seriously wrong. I triple-checked everything, but Declaration::Compare is not even called when the error is triggered! How should we proceed now? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [BUG?] Confusion between translation units?
So first, an addendum: I found a way to make the project build without
using a symlink, and use a direct reference instead. The problem still
persists. It may be that symlink is one of the problems, but it is
certainly not the only problem.
On Tue, Oct 20, 2015 at 8:22 PM, Greg Clayton wrote:
> int
> Declaration::Compare(const Declaration& a, const Declaration& b)
> {
> int result = FileSpec::Compare(a.m_file, b.m_file, true);
> if (result)
Wait, won't FileSpec::Compare be true iff a.m_file is the same as
b.m_file (excluding symlink resolution)? If so, why are we putting the
symlink-checking logic in the true branch of the original
FileSpec::Compare? Aren't we expanding the scope of what we match,
instead of narrowing it?
> {
> int symlink_result = result;
> if (a.m_file.GetFilename() == b.m_file.GetFilename())
> {
> // Check if the directories in a and b are symlinks to each other
> FileSpec resolved_a;
> FileSpec resolved_b;
> if (FileSystem::ResolveSymbolicLink(a.m_file,
> resolved_a).Success() &&
> FileSystem::ResolveSymbolicLink(b.m_file,
> resolved_b).Success())
> {
> symlink_result = FileSpec::Compare(resolved_a, resolved_b,
> true);
I'm confused. Shouldn't the logic be "check literal equality; if true,
return immediately; if not, check equality with symlink resolution"?
> }
> }
> if (symlink_result != 0)
> return symlink_result;
> }
> if (a.m_line < b.m_line)
> return -1;
> else if (a.m_line > b.m_line)
> return 1;
> #ifdef LLDB_ENABLE_DECLARATION_COLUMNS
> if (a.m_column < b.m_column)
> return -1;
> else if (a.m_column > b.m_column)
> return 1;
> #endif
> return 0;
> }
Here's my version of the patch, although I'm not sure when the code
will be reached.
int
Declaration::Compare(const Declaration& a, const Declaration& b)
{
int result = FileSpec::Compare(a.m_file, b.m_file, true);
if (result)
return result;
if (a.m_file.GetFilename() == b.m_file.GetFilename()) {
// Check if one of the directories is a symlink to the other
int symlink_result = result;
FileSpec resolved_a;
FileSpec resolved_b;
if (FileSystem::ResolveSymbolicLink(a.m_file, resolved_a).Success() &&
FileSystem::ResolveSymbolicLink(b.m_file, resolved_b).Success())
{
symlink_result = FileSpec::Compare(resolved_a, resolved_b, true);
if (symlink_result)
return symlink_result;
}
}
if (a.m_line < b.m_line)
return -1;
else if (a.m_line > b.m_line)
return 1;
#ifdef LLDB_ENABLE_DECLARATION_COLUMNS
if (a.m_column < b.m_column)
return -1;
else if (a.m_column > b.m_column)
return 1;
#endif
return 0;
}
If you're confident that this solves a problem, I can send it as a
code review or something (and set up git-svn, sigh).
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [BUG?] Confusion between translation units?
Hi, On Wed, Oct 21, 2015 at 2:27 PM, Greg Clayton wrote: > Atleast, can we have lldb report a nicer error? There is conflicting DWARF information for type ilist...: /sandbox/rramacha/3p/derived/List.h /sandbox/rramacha/3p/install/List.h /sandbox/rramacha/idivide/bin/libmwcgir_vm.so is to blame. This is likely a problem with your build scripts. In any case, the compiler is responsible for this mess. > It sounds like you fixed your symlink issue. So a few questions: > 1 - do you have just one type now in your libmwcgir_vm_rt.dylib.dSYM when you > type: > > (lldb) image lookup -t "iplist llvm::ilist_traits >" > > If so, then you will need to find other competing definitions in other shared > libraries and see if any of them differ by comparing the full "clang_type" > value. Yeah, after resolving the symlink, I realized that there are two different paths. I'm attempting to fix my build system. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [BUG?] Confusion between translation units?
Okay, I'm stuck again. Let's back up and see what's happening: ~/src$ git clone llvm/ ~/src$ mkdir llvm-build/ ~/src/llvm-build$ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug ../llvm ~/src/llvm-build$ ninja Now, ~/src/llvm-build/lib/libLLVMCore.a contains DWARF information that points to files ~/src/llvm/include/llvm/ADT/ilist.h, ~/src/llvm/lib/IR/Core.cpp etc. ~/src/llvm-build$ ninja install The *.a files are copied to /usr/local/lib, but the *.h files are also copied to /usr/local/include/llvm. The DWARF information is not rewritten as part of the "install". ~/src/fooapp$ clang++ -g -I/usr/local/include -L/usr/local/lib ... The fooapp binary is going to contain DWARF information pointing to /usr/local/include/llvm/ADT/ilist.h (because I did -I) _and_ ~/src/llvm/include/llvm/ADT/ilist.h (because of libLLVMCore.a). lldb crashes. gdb hums along just fine in the face of this conflict (the codebase is enormous; sorry, I couldn't find out how exactly). Now, I cannot "fix" my build by -I'ing ~/src/llvm/include because some essential headers are build artifacts. The only thing I can do is to try and put a plist into the dSYM (which doesn't seem to work either, or I'm doing something wrong). In the general case, there's nothing special about my build: this problem needs to be solved in lldb for the general audience. Please advise. Thanks. Ram On Fri, Oct 23, 2015 at 1:00 PM, Greg Clayton wrote: > I guess LLDB was just helping your resolve build issues and make your product > better... :-) > > Let us know how things go once you get your build fixed. > > Greg > >> On Oct 23, 2015, at 9:45 AM, Ramkumar Ramachandra wrote: >> >> Hi, >> >> On Wed, Oct 21, 2015 at 2:27 PM, Greg Clayton wrote: >>> >> >> Atleast, can we have lldb report a nicer error? >> >> There is conflicting DWARF information for type ilist...: >> /sandbox/rramacha/3p/derived/List.h >> /sandbox/rramacha/3p/install/List.h >> >> /sandbox/rramacha/idivide/bin/libmwcgir_vm.so is to blame. >> >> This is likely a problem with your build scripts. In any case, the >> compiler is responsible for this mess. >> >>> It sounds like you fixed your symlink issue. So a few questions: >>> 1 - do you have just one type now in your libmwcgir_vm_rt.dylib.dSYM when >>> you type: >>> >>> (lldb) image lookup -t "iplist>> llvm::ilist_traits >" >>> >>> If so, then you will need to find other competing definitions in other >>> shared libraries and see if any of them differ by comparing the full >>> "clang_type" value. >> >> Yeah, after resolving the symlink, I realized that there are two >> different paths. I'm attempting to fix my build system. > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [BUG?] Confusion between translation units?
Greg, Greg Clayton wrote: > Note that for C++ we get the fully qualified name and we pass in an empty > Declaration() so they all will compare to the same thing. This would solve > our current issue. We would also need to add the items to this map in the > same way: for C++ get the fully qualified name and add the entry to the map > with the fully qualified name and an empty Declaration... I didn't realize that the solution would be this simple, conceptually. > Can you try this solution out and see if it fixes our issues? This does seem to work for one library but not another. My best guess would be that the solution works when dynamically linking to conflicting symbols, but not when the conflicting symbols are statically linked. Does that make sense? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Debugging lldb with lldb: infinite process interrupt?
Hi, I'm using lldb to debug lldb, and I notice that I get this message in the inner lldb: (lldb) p F error: Process is running. Use 'process interrupt' to pause execution. If I 'process interrupt', I go to the outer lldb (presumably), and if I try to 'continue', the same message is displayed over and over again. This only happens _sometimes_, and I can't quite explain when. Any clues? Ram ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
