FWIW, as a happy lldb user, it's exciting to read about these planned
developments.
I have two follow-up questions about the section on 'Testing Strategy
Evaluation': (1) what is lldb's policy on including test updates with bug fix
commits and functional changes, and (2) how is this policy enforce
https://llvm.org/bugs/show_bug.cgi?id=28910
Bug ID: 28910
Summary: Add frame-finish breakpoints
Product: lldb
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> LLDB has come a long way since the project was first announced. As a
> robust debugger for C-family languages and Swift, LLDB is constantly in use
> by millions of developers. It has also become a foundati
LLDB has come a long way since the project was first announced. As a robust
debugger for C-family languages and Swift, LLDB is constantly in use by
millions of developers. It has also become a foundation for bringing up
debugger support for other languages like Go and RenderScript. In additio
> On Aug 1, 2016, at 2:40 PM, Vedant Kumar via lldb-dev
> wrote:
>
> Hi lldb-dev,
>
> It looks like the debugger initializes static variables in llvm (see:
> SystemInitializerFull::Initialize()), but, AFAICT, it never cleans them up.
>
> Does this cause memory leaks? I'd assumed that it's nec
Hi,
thanks for the patch. I took the opportunity to clean up the code
there, so I have committed a somewhat modified version, but I believe
you should get the result you were trying to achieve. Let me know how
it works.
cheers,
pl
On 2 August 2016 at 13:53, Dangling Pointer via lldb-dev
wrote:
