lldb cannot properly translate qualified enum value if a intermediate nested class is private |
|
Issue descriptionTo reproduce: * Sync to Chromium commit 0877ce62e907e9a76083121c29ce4c7d31f2949f (p463777) and build net_unittests. (I can't imagine the Chromium commit matters very much, except possibly for the line number for the breakpoint below.) * Build lldb from tree tip. The commits I used (via "git pull" today) were: ** llvm: d8dec6c86f982f17e9d06aff22f680e1fe3a8784 ** clang: dbf1b8007c7d43ca8c802b277a75785f1c0ed3ae ** 449d2091fc0842092b317d3db3c72a2b6fbf1a6e Log showing problems converting state value. If these show multiple problems (or pilot error for some problems) please focus on the first failure, as what I'm trying to do is eventually create a function via expression -- \n <fndef> to convert from state values to strings for debug logging. The problem may not actually be the private class, that was just my best guess when the top level refused to recognize 'Transacation' (which is defined in its own .h file, but its relationship with HttpCache is specified in the http_cache.h file via a "class Transaction" after the private: label). rdsmith-macbookpro:../chrome/src [master] $ lldb out/Default/net_unittests lldb out/Default/net_unittests (lldb) target create "out/Default/net_unittests" Current executable set to 'out/Default/net_unittests' (x86_64). (lldb) p net::HttpCache::Transaction::STATE_NONE p net::HttpCache::Transaction::STATE_NONE error: 'Transaction' is not a class, namespace, or enumeration (lldb) break set -f http_cache_transaction.cc -l 710 break set -f http_cache_transaction.cc -l 710 Breakpoint 1: where = libnet.dylib`net::HttpCache::Transaction::DoLoop(int) + 570 at http_cache_transaction.cc:710, address = 0x0000000000637afa (lldb) run --gtest_filter=HttpCache.RangeGET_NoStrongValidators run --gtest_filter=HttpCache.RangeGET_NoStrongValidators Process 26803 launched: '/Users/rdsmith/Sandboxen/chrome/src/out/Default/net_unittests' (x86_64) Debugger detected, switching to single process mode. Pass --test-launcher-debug-launcher to debug the launcher itself. Detected presence of a debugger, running without test timeouts. Note: Google Test filter = HttpCache.RangeGET_NoStrongValidators [==========] Running 1 test from 1 test case. [----------] Global test environment set-up. [----------] 1 test from HttpCache [ RUN ] HttpCache.RangeGET_NoStrongValidators Process 26803 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x00000001092dfafa libnet.dylib`net::HttpCache::Transaction::DoLoop(this=0x000000010e02ee00, result=0) at http_cache_transaction.cc:710 707 int rv = result; 708 do { 709 State state = next_state_; -> 710 next_state_ = STATE_UNSET; ^ 711 base::AutoReset<bool> scoped_in_do_loop(&in_do_loop_, true); 712 713 switch (state) { (lldb) p net::HttpCache::Transaction::STATE_NONE p net::HttpCache::Transaction::STATE_NONE error: reference to 'HttpCache' is ambiguous candidate found by name lookup is 'net::HttpCache' candidate found by name lookup is 'net::HttpCache' (lldb) p HttpCache::Transaction::STATE_NONE p HttpCache::Transaction::STATE_NONE error: 'Transaction' is not a class, namespace, or enumeration error: reference to 'Transaction' is ambiguous candidate found by name lookup is 'Transaction' candidate found by name lookup is 'Transaction' (lldb) p Transaction::STATE_NONE p Transaction::STATE_NONE error: reference to 'Transaction' is ambiguous candidate found by name lookup is 'Transaction' candidate found by name lookup is 'Transaction' (lldb) p STATE_NONE p STATE_NONE (int) $0 = 1 (lldb)
,
Apr 13 2017
Nope; I'm not familiar with the best ways to debug these problems :-}. expr.log from the initial problem shown above (without running any tests and breaking to change the evaluation context) attached. Let me know if you want pointers to the relevant .h files.
,
Apr 13 2017
What is the policy with sharing this information outside of Google? Even when I worked at Apple, I was not the resident expert in the LLDB expression parser (the guy that kicks in when you "p" something) I know a few people still in DevTools over there, but my suggested course of action would be to forward this issue to the LLDB bugzilla (http://bugs.llvm.org/) with expression log and as much other info as you can reasonably provide. Also, IIRC, the ambiguous reference problem you're seeing is a somewhat known issue - as in, it popped up every so often in tricky C++ codebases, but we never had the time to sit down and squash it once and for all.
,
Apr 13 2017
This bug is public, and chromium's an open source project; we can share whatever's useful. The reason I didn't go with filing a bug on that bug tracker in the first place is that I think of those folks as (not unreasonably) wanting a repro case that is boiled down from the large mess that is the CPP output of compiling a chromium file, and I think that would take me a lot longer to do than creating a repro based on Chrome code. And it being a somewhat known issue makes me have even less enthusiasm for the process of filing a bug @ llvm.org, since it sounds like a reasonably likely result is "Yeah, we know--patches welcome" :-J. But if you think it's possible to get some traction with the amount of information I can provide without spending too much time creating a minimal repro, I'm happy to give it a try.
,
Apr 18 2017
I filed an upstream bug with a reduced test case as http://bugs.llvm.org/show_bug.cgi?id=32702
,
Apr 18 2017
Thank you both! |
|
►
Sign in to add a comment |
|
Comment 1 by egranata@google.com
, Apr 13 2017