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

[Nat! via lldb-dev]

I use a plugin in Visual Studio Code 
https://github.com/WebFreak001/code-debug, that uses lldb-mi. It works 
fairly well for me.


Ciao
   Nat!


On 02.07.19 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 as I can tell it's missing core functionality to be 
usable from something like say emacs.


Thanks,
Jonas

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Jim Ingham via lldb-dev]

> On Jul 2, 2019, at 11:52 AM, Vangelis Tsiatsianas  
> wrote:
> 
> I would like to leave it as a suggestion for the future, just in case the 
> need for such a mechanism arises in other places within LLDB or for plugins.

File an enhancement request with bugs.llvm.org, otherwise it will get lost.  
There's also a Projects page at lldb.llvm.org with a list of interesting ideas 
for additions to lldb - another place to mention this sort of enhancement - 
hough we should probably get more general agreement that this is a good 
direction before putting it there.

Jim


> 
> Thank you, once again, for your time and very helpful responses! 
> 
> 
> ― Vangelis
> 
> 
>> On 2 Jul 2019, at 02:16, Jim Ingham  wrote:
>> 
>> 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 threads to affect that doesn't seem out of line to me.
>> 
>> Jim
>> 
>> 
>>> On Jul 1, 2019, at 4:00 PM, Vangelis Tsiatsianas  
>>> wrote:
>>> 
>>> 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-thread") by registering a callback, which 
>>> would be triggered every time a "settings set" or similar settings 
>>> modification command was issued, like:
>>> 
>>> Settings::RegisterCallback(std::string setting_value_name, 
>>> std::function callback);
>>> 
>>> 
>>> That way, ThreadPlanTracer could do:
>>> 
>>> Settings::RegisterCallback("target.process.thread.trace-thread", 
>>> [](std::string new_value) {
>>>   if (new_value == "true") {
>>>   EnableTracing();
>>>   } else {
>>>   DisableTracing();
>>>   }
>>> });
>>> 
>>> …instead of having to query the setting every time. 
>>> 
>>> 
>>> ― Vangelis
>>> 
>>> 
 On 1 Jul 2019, at 20:18, Jim Ingham  wrote:
 
 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, select make a new revision from the popup and fill out the form.
 
> On Jun 29, 2019, at 11:57 PM, Vangelis Tsiatsianas 
>  wrote:
> 
> Thank you very much for your replies! 
> 
> I took a look at ThreadPlanTracer and found out that the crash reason was 
> the call of a virtual method during object construction:
> 
> virtual Process.UpdateThreadList()
> └── ProcessGDBRemote.UpdateThreadList()
>  └── new ThreadGDBRemote()
>  └── new Thread()
>  └── new ThreadPlanBase()
>  ├── new ThreadPlanAssemblyTracer()
>  └── virtual ThreadPlanAssemblyTracer::EnableTracing()
>  └── virtual ThreadPlanTracer::TracingStarted()
>  └── virtual Thread::GetRegisterContext() ← Virtual 
> method call of Thread under construction!
>  └── __cxa_pure_virtual()
> 
> I believe I fixed the bug and also tried to make the tracing API a little 
> better.
 
 Thanks!  I'll take a look when it is up for review.
 
> 
> In order to correct the logic, I had to add a call to 
> Thread::GetTraceEnabledState() (somewhat expensive) in 
> Thread::ShouldStop(), which looks like a hot path and thus I was a bit 
> hesitant about it. Ideally, changing a setting (here: 
> target.process.thread.trace-thread) should trigger a callback, however I 
> couldn’t find any such mechanism ―does it exist?
 
 My intention was that you would derive from ThreadPlanTracer, and then you 
 could do whatever reporting you wanted in the ShouldStop method of the 
 Tracer.  Kind of like what the ThreadPlanAssemblyTracer does.  But I was 
 mostly thinking of this as an internal facility.  To make it available 
 from LLDB's public face, you could do allow folks to write a scripted 
 thread plan.  But it might be simpler to just register a callback and have 
 the extant ThreadPlanAssemblyTracer class call it in its Log method.
 
 Jim
 
> 
> You may find the relevant patch attached. It was generated against 
> llvm-8.0.0 git tag (commit SHA: d2298e74235598f15594fe2c99bbac870a507c59).
> 
> 
> ― Vangelis
> 
> 
> P.S.: How can I submit this patch for review?
> 
> 
> 
> 
>> On 28 Jun 2019, at 20:50, Jim Ingham  wrote:
>> 
>> Stop hooks only trigger when control is about to be returned to the 
>> user.  And 

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

[Vangelis Tsiatsianas via lldb-dev]

I would like to leave it as a suggestion for the future, just in case the need 
for such a mechanism arises in other places within LLDB or for plugins.

Thank you, once again, for your time and very helpful responses! 


― Vangelis


> On 2 Jul 2019, at 02:16, Jim Ingham  wrote:
> 
> 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 threads to affect that doesn't seem out of line to me.
> 
> Jim
> 
> 
>> On Jul 1, 2019, at 4:00 PM, Vangelis Tsiatsianas  
>> wrote:
>> 
>> 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-thread") by registering a callback, which would 
>> be triggered every time a "settings set" or similar settings modification 
>> command was issued, like:
>> 
>> Settings::RegisterCallback(std::string setting_value_name, 
>> std::function callback);
>> 
>> 
>> That way, ThreadPlanTracer could do:
>> 
>> Settings::RegisterCallback("target.process.thread.trace-thread", 
>> [](std::string new_value) {
>>if (new_value == "true") {
>>EnableTracing();
>>} else {
>>DisableTracing();
>>}
>> });
>> 
>> …instead of having to query the setting every time. 
>> 
>> 
>> ― Vangelis
>> 
>> 
>>> On 1 Jul 2019, at 20:18, Jim Ingham  wrote:
>>> 
>>> 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, select make a new revision from the popup and fill out the form.
>>> 
 On Jun 29, 2019, at 11:57 PM, Vangelis Tsiatsianas  
 wrote:
 
 Thank you very much for your replies! 
 
 I took a look at ThreadPlanTracer and found out that the crash reason was 
 the call of a virtual method during object construction:
 
 virtual Process.UpdateThreadList()
 └── ProcessGDBRemote.UpdateThreadList()
   └── new ThreadGDBRemote()
   └── new Thread()
   └── new ThreadPlanBase()
   ├── new ThreadPlanAssemblyTracer()
   └── virtual ThreadPlanAssemblyTracer::EnableTracing()
   └── virtual ThreadPlanTracer::TracingStarted()
   └── virtual Thread::GetRegisterContext() ← Virtual 
 method call of Thread under construction!
   └── __cxa_pure_virtual()
 
 I believe I fixed the bug and also tried to make the tracing API a little 
 better.
>>> 
>>> Thanks!  I'll take a look when it is up for review.
>>> 
 
 In order to correct the logic, I had to add a call to 
 Thread::GetTraceEnabledState() (somewhat expensive) in 
 Thread::ShouldStop(), which looks like a hot path and thus I was a bit 
 hesitant about it. Ideally, changing a setting (here: 
 target.process.thread.trace-thread) should trigger a callback, however I 
 couldn’t find any such mechanism ―does it exist?
>>> 
>>> My intention was that you would derive from ThreadPlanTracer, and then you 
>>> could do whatever reporting you wanted in the ShouldStop method of the 
>>> Tracer.  Kind of like what the ThreadPlanAssemblyTracer does.  But I was 
>>> mostly thinking of this as an internal facility.  To make it available from 
>>> LLDB's public face, you could do allow folks to write a scripted thread 
>>> plan.  But it might be simpler to just register a callback and have the 
>>> extant ThreadPlanAssemblyTracer class call it in its Log method.
>>> 
>>> Jim
>>> 
 
 You may find the relevant patch attached. It was generated against 
 llvm-8.0.0 git tag (commit SHA: d2298e74235598f15594fe2c99bbac870a507c59).
 
 
 ― Vangelis
 
 
 P.S.: How can I submit this patch for review?
 
 
 
 
> On 28 Jun 2019, at 20:50, Jim Ingham  wrote:
> 
> Stop hooks only trigger when control is about to be returned to the user. 
>  And in its normal mode, lldb doesn't step instruction all the time 
> anyway...  So I don't think they would do what Vangelis wants.  He would 
> have to drive the debugger with only the step-instruction command, which 
> I think qualifies as interfering with stepping.
> 
> The ThreadPlanTracer is really the ticket, it does force the debugging to 
> only instruction single step when it is realizing the more complex 
> stepping operations, and then has hooks on each instruction stop.
> 
> Sean and I 

[lldb-dev] 2019 LLVM Dev Mtg (Bay Area) - Call for presentations

[Tanya Lattner via lldb-dev]

All developers and users of LLVM and related sub-projects are invited to 
present at the 2019 LLVM Developers’ Meeting - Bay Area 
.

We are looking for the following proposals:
Technical Talks (25-30 minutes including Q):
- On LLVM Infrastructure,Clang and all related sub-projects
- On uses of LLVM in academia or industry
- On new projects using Clang or LLVM
Tutorials (60 minutes)
- In depth talks on LLVM infrastructure or other core libraries
Student Research Competition Technical Talks & Poster (20-25 minutes including 
Q)
Lightning Talks (5 minutes, no questions, no discussions)
Birds of a Feather 
 (30 minutes)**
Panels (30-60 minutes)**
Posters (1 hour)


** As the LLVM Developers’ Meeting as grown in size, we are moving away from 
formal Birds of a Feather sessions in favor of smaller informal round table 
discussions. These round table topics can be proposed closer to the LLVM 
Developers’ Meeting and are designed for a smaller and more engaged group of 
developers. Therefore, we are encouraging and recommending that instead of a 
birds of a feather sessions, that developers consider proposing a panel 
discussion. This would mean that several experts on a topic (and a moderator) 
would get together and have an open discussion in front of an audience with 
prepared questions and also questions from the audience. The program committee 
will be looking for these proposals and giving favor to them over more 
traditional birds of a feather proposals that we have had in the past.

Submission Requirements:
The submission deadline is August 12, 2019 at 11:59PM PDT.

Please submit your proposal here:
LLVM2019 Home 
For each proposal, please submit a title, short abstract, submission type, 
abstract for the website, include who the speakers or panel member/moderators 
are, and provide a more detailed description of the talk through an extended 
PDF abstract. We highly recommend you consult and follow the guide at the end 
of this CFP when submitting your proposal.

Student Research Competition (SRC):
We will again have a Student Research Competition (SRC). The SRC offers 
students doing LLVM related research a non-academic platform to announce and 
advertise their work as well as to discuss it with other researchers, 
developers and users of LLVM. Students are asked to submit a proposal for a 
20-25 minute technical talk. There will be a prize for the best SRC talk.

FAQ

When will I be notified of acceptance?

Our goal is to notify all submissions by August 27, 2019.

What are panels?

Panels may discuss any topic as long as it’s relevant to LLVM or related 
sub-projects. Panels can take many forms, but a common format is to begin with 
short introductions from each panel member, and follow with an interactive 
dialogue among the panelists and audience members. Panels should consist of 3 
people including a moderator.

Should I register if I have submitted a proposal?

We have 1 complimentary reserved  registration for each accepted technical 
talk, BoF, or student research competition talk. Accepted tutorials have been 
reserved 2 complimentary registrations. Panels have up to 3 reserved 
registrations. There are no reserved registration spots for posters or 
lightning talks. So please register any additional speakers or if you do not 
have a reserved registration slot.

What if I registered and my talk got accepted?

We can refund your registration fee and instructions will be sent following 
notification.  If you plan to attend even if your proposal is not accepted and 
are worried about the event selling out, we suggest registering before 
notification of acceptance.

What if I registered and my talk DID NOT get accepted?

We can refund your registration fee if you no longer wish to attend if you 
contact the organizer by September 22, 2019.

What will be recorded?

All technical talks, tutorials, SRC talks, panels, and lightning talks will be 
recorded. By submitting your proposal, you are giving us permission to record 
if you present at the meeting. For SRC talks, you have the option to delay 
publication of the slides and video for you talk for up to 12 months.

Who is on the program committee?

Our program committee chair is David Blaikie. The program committee is composed 
of active developers of the LLVM, Clang, and related sub-communities. The 
website will be updated with the list of the program committee members.

I have a question, who do I contact?

Please email the LLVM Dev Mtg Organizers (devmtg-organiz...@lists.llvm.org), or 
the LLVM Developers’ Meeting mailing list. 
http://lists.llvm.org/mailman/listinfo/llvm-devmeeting 


Detailed guidance on writing a proposal for the LLVM Developers’ Meeting

Writing a proposal for the LLVM Developers’ Meeting

This document is a guide to help you submit the best 

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

[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 as I can tell it's missing core functionality to be 
usable from something like say emacs.




I am in favour of this proposal, for all of the reasons stated above. 
Since lldb-mi uses lldb stable API, any interested parties can easily 
create a separate project for it on github (or wherever). Maybe this 
would even serve as a spark to reignite lldb-mi development (which has 
been sitting in idle for quite some time now).


pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev