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

[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 
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 added this facility way way back in the early days of lldb 
 because we needed it to figure out some problems with the expression 
 parser.  We weren't really sure whether we were going to promote it more 
 broadly and were waiting for some more interest to spend time cleaning it 
 up and writing tests, etc.  Then years passed... So it is not entirely 
 surprising that the facility 

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

[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-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 added this facility way way back in the early days of lldb 
>>> because we needed it to figure out some problems with the expression 
>>> parser.  We weren't really sure whether we were going to promote it more 
>>> broadly and were waiting for some more interest to spend time cleaning it 
>>> up and writing tests, etc.  Then years passed... So it is not entirely 
>>> surprising that the facility needs some attention.  If somebody wants to 
>>> take a stab at making this work reliably again, that would be awesome!
>>> 
>>> Jim
>>> 
>>> 
>>> 
 On Jun 28, 2019, at 7:09 AM, Ted Woodward via lldb-dev 
  wrote:
 
 You want to set up a stop-hook.
 
 See “help target stop-hook”, specifically “help target stop-hook add”.
 
 target stop-hook add -o “register read pc”
 will read the pc each time the target stops.
 
 From: lldb-dev  On Behalf Of Vangelis 
 

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

[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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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 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] [RFC] Removing lldb-mi

[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
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] 2019 LLVM Developers' Meeting (Bay Area) - Registration open

[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
 


The LLVM Developers' Meeting is a bi-annual 2 day gathering of the entire LLVM 
Project community. The conference is organized by the LLVM Foundation and many 
volunteers within the LLVM community. Developers and users of LLVM, Clang, and 
related subprojects will enjoy attending interesting talks, impromptu 
discussions, and networking with the many members of our community. Whether you 
are a new to the LLVM project or a long time member, there is something for 
each attendee.

Tickets for the 2-day conference & reception are $350, and $300 for just the 
2-day conference. Student tickets are $75/$50 and we ask that you use your 
student email during registration. Please note that early registration will end 
on September 22 at 11:59 PDT and a late registration (and increased rates) will 
go into effect after this date. We highly encourage you to register early. 

Our ticket prices are subsidized by almost 50% by generous corporate sponsors 
 and public donations. However, for 
those in a position to pay the full ticket cost (or your employer), we invite 
you to select the Supporter Ticket option during registration. This ticket 
price is based upon our estimated cost for the event per person. By purchasing 
this ticket, it will allow us to keep ticket prices low and fund other programs 
such as more Educational Outreach, Travel Grants & Scholarships, Women in 
Compilers & Tools, and LLVM project infrastructure. 

New this year: We will have a newcomers orientation 

 on October 21, from 5:45-6:30PM. This is a short session for those attending 
the LLVM Developers' Meeting for the first time or for those who have not 
attended in awhile. This orientation will provide a conference overview, and 
useful information on how to participate and get involved during the 
conference. If you are interested in networking and meeting other new LLVM 
Developers, then you should attend this event. There is a separate EventBrite 
page 

 to register.

There will also be a Women in Compilers and Tools Workshop the day before on 
October 21st (~12:30-6:30pm). Details will be coming soon on this event.

What can you can expect at an LLVM Developers' Meeting?

• Technical Talks: These 20-30 minute talks cover all topics from core 
infrastructure talks, to project's using LLVM's infrastructure. Attendees will 
take away technical information that could be pertinent to their project or 
general interes. 
• Tutorials: Tutorials are 50 minute sessions that dive down deep into 
a technical topic. Expect in depth examples and explanations.
• Lightning Talks: These are fast 5 minute talks that give you a taste 
of a project or topic. Attendees will hear a wide range of topics and probably 
leave wanting to learn more.
• Panels: Panel sessions are guided discussions about a specific topic. 
The panel consists of ~3 developers who discuss a topic through prepared 
questions from a moderator. The audience is also given the opportunity to ask 
questions of the panel.
• Student Research Competition: Students present their research using 
LLVM or related subproject. These are usually 20 minute technical presentations 
with Q The audience will vote at the end for the winning presentation and 
paper.
• Poster Session: An hour long poster session where selected posted are 
on display.
• Round Table Discussions: Informal and impromptu discussions on a 
specific topic. During the conference there are set time slots where groups can 
organize to discuss a problem or topic.
• Evening Reception (October 22): After a full day if technical talks 
and discussions, join your fellow attendees for an evening reception to 
continue the conversation and meet even more attendees.

What types of people attend?
• Active developers of projects in the LLVM Umbrella (LLVM core, Clang, 
LLDB, libc++, compiler_rt, klee, lld, etc).
• Anyone interested in using these as part of another project.
• Students and Researchers
• Compiler, programming language, and runtime enthusiasts.
• Those interested in using compiler and toolchain technology in novel 
and interesting ways.

For future announcements or questions: Please sign up for the LLVM Developers’ 
Meeting mailing list 

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

[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
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: spmichaels.w...@gmail.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

LLDB's GDB remote protocol implementation defines a parser for the 'A' packet
at tools/debugger/source/RNBRemote.cpp:1538 (i.e. RNBRemote::HandlePacket_A()).
This packet is used to pass an argv[] array to the program.

GDB's remote protocol spec defines the A packet as follows (see
(https://sourceware.org/gdb/onlinedocs/gdb/Packets.html):

---
‘A arglen,argnum,arg,…’

Initialized argv[] array passed into program. arglen specifies the number of
bytes in the hex encoded byte stream arg. See gdbserver for more details.
---

Note that `gdbserver` does not actually implement the A packet (see
https://github.com/bminor/binutils-gdb/blob/master/gdb/gdbserver/server.c), so
the note to "See gdbserver for more details" is moot.


LLDB's implementation assumes that 'arglen' and 'argnum' are base-10 unsigned
integers. However, the GDB remote protocol overview specifies that (see
https://sourceware.org/gdb/onlinedocs/gdb/Overview.html#Overview):

---
Except where otherwise noted all numbers are represented in HEX with leading
zeros suppressed.
---

Since the 'A' packet definition does not explicitly specify a base for arglen
and argnum, thesei should actually be base-16, not base-10 as they are now.

This would require changes to the two `strtoul()` calls on lines 1562 and 1574
of `RNBRemote.cpp`.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
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]

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 added this facility way way back in the early days of lldb 
>> because we needed it to figure out some problems with the expression parser. 
>>  We weren't really sure whether we were going to promote it more broadly and 
>> were waiting for some more interest to spend time cleaning it up and writing 
>> tests, etc.  Then years passed... So it is not entirely surprising that the 
>> facility needs some attention.  If somebody wants to take a stab at making 
>> this work reliably again, that would be awesome!
>> 
>> Jim
>> 
>> 
>> 
>>> On Jun 28, 2019, at 7:09 AM, Ted Woodward via lldb-dev 
>>>  wrote:
>>> 
>>> You want to set up a stop-hook.
>>> 
>>> See “help target stop-hook”, specifically “help target stop-hook add”.
>>> 
>>> target stop-hook add -o “register read pc”
>>> will read the pc each time the target stops.
>>> 
>>> From: lldb-dev  On Behalf Of Vangelis 
>>> Tsiatsianas via lldb-dev
>>> Sent: Friday, June 28, 2019 6:16 AM
>>> To: via lldb-dev 
>>> Cc: Vangelis Tsiatsianas 
>>> Subject: [EXT] [lldb-dev] Enabling single-step mode and acting on each 
>>> executed instruction
>>> 
>>> Hello,
>>> 
>>> I would like to set the target in single-step mode and perform an action 
>>> right after each instruction is executed. Notably, it is crucial to do so 
>>> transparently, i.e. without interfering with user breakpoints, watchpoints, 
>>> stepping etc..
>>> 
>>> Could you provide me with some guidance on how to accomplish it? 
>>> 
>>> I have found the target.process.thread.trace-thread option and the relevant 
>>> classes (ThreadPlanTracer and ThreadPlanAssemblyTracer), which although 
>>> seem to not work and also crash the debugger when enabled.
>>> 
>>> Thank you very much, in advance.
>>> 
>>> 
>>> ― Vangelis
>>> 
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 

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

[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 from SymbolVendor::FindFunctions() holding a module lock
across the delegated FindFunctions() call, which for SymbolFileDWARF
results in TaskMapToInt() passing the task to a worker "task runner"
thread. With DWARF logging enabled the worker thread calls
Module::GetDescription() from LogMessageVerboseBacktrace(), which tries to
claim the same mutex.

With a simple workaround (don't always enable DWARF logging) this
particular instance is easy to avoid but perhaps there are other cases or
some wider implications, e.g. rules for task runner behaviour to avoid such
states? (possibly part of the problem is that the FindFunctions() interface
looks synchronous so holding a recursive mutex across the call isn't
obviously risky)
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev