Re: [lldb-dev] [RFC] Removing lldb-mi

2019-07-01 Thread Pavel Labath via lldb-dev
On 02/07/2019 00:09, Jonas Devlieghere via lldb-dev wrote: Hi everyone, After long consideration, I want to propose removing lldb-mi from the repository. It is basically unmaintained, doesn't match the LLDB code style, and worst of all the tests are unreliable if not already disabled. As far

Re: [lldb-dev] Enabling single-step mode and acting on each executed instruction

2019-07-01 Thread Jim Ingham via lldb-dev
There isn't a general mechanism for external clients to watch settings changes. But IMO, it would be appropriate for the setter for the target.process.thread.trace-thread set function to go do this work. Having an explicit relationship between setting the setting and changing state in the thr

Re: [lldb-dev] Enabling single-step mode and acting on each executed instruction

2019-07-01 Thread Vangelis Tsiatsianas via lldb-dev
Thank you! I created the revision and added you as a reviewer (https://reviews.llvm.org/D64043 ). Regarding the callback mechanism, I was thinking more of components having the ability to express interest in a setting value (e.g. "target.process.thread.trace-thr

Re: [lldb-dev] [RFC] Removing lldb-mi

2019-07-01 Thread Davide Italiano via lldb-dev
On Mon, Jul 1, 2019 at 3:21 PM Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > We’re using lldb-mi to debug with Eclipse in the Hexagon SDK. I’d really > like to keep it! 😊 > > > Is there any reason why this can't be a downstream project? Thanks, -- Davide

Re: [lldb-dev] [RFC] Removing lldb-mi

2019-07-01 Thread Ted Woodward via lldb-dev
We’re using lldb-mi to debug with Eclipse in the Hexagon SDK. I’d really like to keep it! 😊 Ted From: lldb-dev On Behalf Of Jonas Devlieghere via lldb-dev Sent: Monday, July 1, 2019 5:09 PM To: LLDB Subject: [EXT] [lldb-dev] [RFC] Removing lldb-mi Hi everyone, After long consideration, I wa

[lldb-dev] [RFC] Removing lldb-mi

2019-07-01 Thread Jonas Devlieghere via lldb-dev
Hi everyone, After long consideration, I want to propose removing lldb-mi from the repository. It is basically unmaintained, doesn't match the LLDB code style, and worst of all the tests are unreliable if not already disabled. As far as I can tell it's missing core functionality to be usable from

[lldb-dev] 2019 LLVM Developers' Meeting (Bay Area) - Registration open

2019-07-01 Thread Tanya Lattner via lldb-dev
The LLVM Foundation is pleased to announce the 13th annual LLVM Developers’ Meeting in the Bay Area on October 22-23, 2019 in San Jose, CA. Registration is now open! https://www.eventbrite.com/e/2019-llvm-developers-meeting-bay-area-tickets-63481303287

[lldb-dev] [Bug 42471] New: GDB remote protocol 'A' packet format is not spec-compliant

2019-07-01 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=42471 Bug ID: 42471 Summary: GDB remote protocol 'A' packet format is not spec-compliant Product: lldb Version: 8.0 Hardware: All OS: All Status: NEW

Re: [lldb-dev] Enabling single-step mode and acting on each executed instruction

2019-07-01 Thread Jim Ingham via lldb-dev
We use http://reviews.llvm.org Click on the Favorites:Differential side bar item, and then on Create Diff in the URH Corner of the window. If you make your diff with: svn diff --diff-cmd=diff -x -U99 or the git equivalent, then they are much easier to review. Once you have the diff, sele

[lldb-dev] Deadlock with DWARF logging and symbol enumeration

2019-07-01 Thread Thomas Goodfellow via lldb-dev
I'm describing this initially through email rather than raising a defect because I haven't developed a usable reproduction (I'm working on an out-of-tree target based off the v8 release) and because it only bites with DWARF logging enabled it's unlikely to affect many people. The deadlock comes fr