One thing I excluded from the newer test results detail info is the
architecture. I personally haven't ever needed that. I'd be happy to
leave that out until we find someone who really needs it, just to keep it
shorter.
On Thu, Dec 3, 2015 at 5:14 PM, Todd Fiala wrote:
> That seems reasonable.
https://llvm.org/bugs/show_bug.cgi?id=25744
Bug ID: 25744
Summary: Linux build breaks when both python 2 and python 3 are
installed
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status:
We don't have anything set up like this at the moment unfortunately. It
could happen in the future, but we've been spending our limited amount of
Windows resources making new debugging scenarios work, and just haven't
gotten to this.
I'd be happy to help diagnose build errors if you're willing to
Yes the debug info does get bigger. But this is better than having the compiler
omit the "std::string" definition so that you can't view stuff from the STL.
Greg
> On Nov 24, 2015, at 7:22 PM, 陶征霖 via lldb-dev wrote:
>
> Also I found that the size of my program binary increases from 140M to 18
Also I found that the size of my program binary increases from 140M to 180M
after -fno-limit-debug-info is added. Seems a lot of debug info is added?
2015-11-25 10:24 GMT+08:00 陶征霖 :
> Hi Pavel,
>
> Thanks for your reply. Seems lldb not finding the variable in the first
> place.
>
> * thread #1:
Hi Pavel,
Thanks for your reply. Seems lldb not finding the variable in the first
place.
* thread #1: tid = 154, 0x00400e5e a.out`main + 94 at t.cpp:5, name
= 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00400e5e a.out`main + 94 at t.cpp:5
2 using namespace std;
Hello,
I have been investigating using the LLDB-MI tool for debugging a project at
work on Windows, but have been unable to work out how to build the program from
source (I spent several days with errors I couldn't work out how to fix before
giving up). Would it be possible to download the bin
The issue is LLDB wants to know information in the registers in the register
context regarding how they map to "generic" registers. For x86_64 this means:
LLDB_REGNUM_GENERIC_PC -> rip
LLDB_REGNUM_GENERIC_SP -> rsp
LLDB_REGNUM_GENERIC_FP -> rbp
LLDB_REGNUM_GENERIC_RA
https://llvm.org/bugs/show_bug.cgi?id=25743
Bug ID: 25743
Summary: TestModulesInlineFunctions.py test_expr() failing on
Darwin
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
https://llvm.org/bugs/show_bug.cgi?id=25742
Bug ID: 25742
Summary: Use After Free Vulnerability lldb_private::Debugger
Product: lldb
Version: 3.4
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: norma
Hi
On 03/12/15 18:02, Greg Clayton wrote:
Each expression has a language so we should be able to get the Language* for
renderscript:
lldb_private::Language* language = lldb_private::Language::FindPlugin
(m_expr.GetLanguage());
Then you can add a new virtual class on lldb_private::Langu
11 matches
Mail list logo
