[lldb-dev] [Bug 28016] New: Assertion failed: (false && "Unhandled quote character")

https://llvm.org/bugs/show_bug.cgi?id=28016 Bug ID: 28016 Summary: Assertion failed: (false && "Unhandled quote character") Product: lldb Version: 3.6 Hardware: Macintosh OS: MacOS X Status: NEW

[lldb-dev] [Bug 28017] New: error: failed to load objectfile for static-linking archives?

https://llvm.org/bugs/show_bug.cgi?id=28017 Bug ID: 28017 Summary: error: failed to load objectfile for static-linking archives? Product: lldb Version: 3.6 Hardware: Macintosh OS: MacOS X Status:

Re: [lldb-dev] [llvm-dev] GitHub anyone?

Chris Lattner writes: >> On Jun 2, 2016, at 11:42 AM, via lldb-dev wrote: >> >> Yeah, I get that and I actually don't mind keeping a linear history. >> But we definitely should branch for release. Given release branches, >> there are a number of questions and tradeoffs about how to backport >>

Re: [lldb-dev] [llvm-dev] GitHub anyone?

On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote: > My only hesitation with this is that this requires use of cherry-pick, > which is not idea. The way most git repositories work is to put > everything that should go into a release branch in the release branch > *first* and then merge

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

+1 to that. I would strongly suggest that we continue to commit to master first, like we've always done in llvm. On Jun 6, 2016 11:44 AM, "Joerg Sonnenberger via cfe-dev" < cfe-...@lists.llvm.org> wrote: > On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote: > > My only hesitation with t

[lldb-dev] [Bug 28019] New: Possibly insecure use of TCP sockets by LLDB

https://llvm.org/bugs/show_bug.cgi?id=28019 Bug ID: 28019 Summary: Possibly insecure use of TCP sockets by LLDB Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal

[lldb-dev] [Bug 28026] New: LLDB-MI doesn't properly output CLI command response using console-stream-output

https://llvm.org/bugs/show_bug.cgi?id=28026 Bug ID: 28026 Summary: LLDB-MI doesn't properly output CLI command response using console-stream-output Product: lldb Version: unspecified Hardware: PC OS: Linux

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

I'd suggest a workflow like the following: - developer commits locally to a feature/bug dev branch. You can commit work in progress, experiments, have bad commit messages etc - developer commits locally to a feature/bug release branch. Tidy up into a small number of logical commits, nice messages

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

On 6 Jun 2016 12:52 p.m., "Bruce Hoult via cfe-dev" wrote: > > I'd suggest a workflow like the following: > > - developer commits locally to a feature/bug dev branch. You can commit work in progress, experiments, have bad commit messages etc > > - developer commits locally to a feature/bug release

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

> On Jun 6, 2016, at 1:29 PM, Richard Smith via llvm-dev > wrote: > > On 6 Jun 2016 12:52 p.m., "Bruce Hoult via cfe-dev" > wrote: > > > > I'd suggest a workflow like the following: > > > > - developer commits locally to a feature/bug dev branch. You can commit

[lldb-dev] Release_38 cherry-picks

Hi all, I'd like to merge a few more small bugfixes onto the 38 release branch. I'll plan to do it tomorrow (3/7) in the evening if I don't hear any objections. Thanks! r259433 - Fix getCompiler in unit testing framework on compiler symlinks r267459 - Add missing qRegisterInfo option to gdbremote

[lldb-dev] Catching async debugger output

Hello, Is there a way for a python script to catch asynchronous debugger output, such as the output of stop hooks? I've tried attaching a listener to CommandInterpreter's broadcaster, but no events seem to be ever fired. Anything else I should try? thanks!