History log of /llvm-project-15.0.7/lldb/source/Target/StopInfo.cpp (Results 1 – 25 of 144)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init
# 83fab8ce 19-Jul-2022 Jim Ingham <[email protected]>

Revert "Make hit point counts reliable for architectures that stop before evaluation."

This reverts commit 5778ada8e54edb2bc2869505b88a959d1915c02f.

The watchpoint tests all stall on aarch64-ubuntu

Revert "Make hit point counts reliable for architectures that stop before evaluation."

This reverts commit 5778ada8e54edb2bc2869505b88a959d1915c02f.

The watchpoint tests all stall on aarch64-ubuntu bots. Reverting till I can
get my hands on an system to test this out.

show more ...


# 4f5707e7 19-Jul-2022 Jim Ingham <[email protected]>

Revert "This is a followup to https://reviews.llvm.org/D129814"

This reverts commit 555ae5b8f5aa93ab090af853a8b7a83f815b3f20.

Apparently, there's something different about how Linux ARM handles wat

Revert "This is a followup to https://reviews.llvm.org/D129814"

This reverts commit 555ae5b8f5aa93ab090af853a8b7a83f815b3f20.

Apparently, there's something different about how Linux ARM handles watchpoints,
as all the watchpoint tests seem to stall on the Ubuntu aarch64 bots.

Reverting till I can get my hands on a linux system and see what is
wrong.

show more ...


# 555ae5b8 18-Jul-2022 Jim Ingham <[email protected]>

This is a followup to https://reviews.llvm.org/D129814

That was causing hit counts to be double-counted on x86_64 Linux.
It looks like StopInfoWatchpoint::ShouldStopSynchronous gets called
twice for

This is a followup to https://reviews.llvm.org/D129814

That was causing hit counts to be double-counted on x86_64 Linux.
It looks like StopInfoWatchpoint::ShouldStopSynchronous gets called
twice for a give stop on Linux (not on Darwin). I had taken out the
"have I been called already" check when I reworked this part of the
code because it didn't seem necessary. Putting that back in because
it looks like it is on some systems.

show more ...


# 5778ada8 13-Jul-2022 Jim Ingham <[email protected]>

Make hit point counts reliable for architectures that stop before evaluation.

Since we want to present the "new & old" values for watchpoint hits, on architectures,
including the ARM family, that st

Make hit point counts reliable for architectures that stop before evaluation.

Since we want to present the "new & old" values for watchpoint hits, on architectures,
including the ARM family, that stop before the triggering instruction is run, we need
to single step over the instruction before stopping for realz. This was incorrectly
done directly in the StopInfoWatchpoint::ShouldStop. That causes problems if more than
one thread stops "for a reason" at the same time as the watchpoint, since the other actions
didn't expect the process to make progress in this part of the execution control machinery.

The correct way to do this is to schedule the step over using ThreadPlans, and then to restore
the stop info after that plan stops, so that the rest of the stop info actions can happen when
all the other threads have handled their immediate actions as well.

Differential Revision: https://reviews.llvm.org/D129814

show more ...


# b8e0b5a0 29-Jun-2022 Jim Ingham <[email protected]>

Threads which hit a breakpoint but fail the condition are considered
not to be hit. But another thread might be hit at the same time and
actually stop. So we have to be sure to switch the first thr

Threads which hit a breakpoint but fail the condition are considered
not to be hit. But another thread might be hit at the same time and
actually stop. So we have to be sure to switch the first thread's
stop info to eStopReasonNone or we'll report a hit when the condition
failed, which is confusing.

Differential Revision: https://reviews.llvm.org/D128776

show more ...


Revision tags: llvmorg-14.0.6
# f22db1fa 16-Jun-2022 Jim Ingham <[email protected]>

Fix StopInfoBreakpoint::ShouldNotify when a callback deletes the site we hit.

When we hit a breakpoint site all of whose owners are internal, we don't
broadcast that event to the public event queue.

Fix StopInfoBreakpoint::ShouldNotify when a callback deletes the site we hit.

When we hit a breakpoint site all of whose owners are internal, we don't
broadcast that event to the public event queue. However, we were checking
whether that was true in the ShouldNotify method, which gets run after the
breakpoint callbacks get run. If the breakpoint callback deletes the site
we just hit, we no longer have the information to make that determination.

This patch just gathers the "was all internal" fact when the StopInfoBreakpoint
gets made, which happens before anyone has a chance to delete the site, and then
uses that cached value.

This bug was causing a couple of tests (including TestStopAtEntry.py) to fail
when using new the macOS Ventura dyld support.

Differential Revision: https://reviews.llvm.org/D127997

show more ...


Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1
# d10c0c7b 17-Mar-2022 Jonas Devlieghere <[email protected]>

[lldb] Migrate condition evaluation failure to ReportError

Migrate to using ReportError to report a failure to evaluate a
watchpoint condition. I had already done so for the parallel code for
breakp

[lldb] Migrate condition evaluation failure to ReportError

Migrate to using ReportError to report a failure to evaluate a
watchpoint condition. I had already done so for the parallel code for
breakpoints.

In the process, I noticed that I accidentally regressed the error
reporting for breakpoint conditions by dropping the call to
GetDescription. This patch rectifies that and adds a test.

Because the call to GetDescription expects a Stream*, I also switches
from using a raw_string_ostream to a StreamString for both breakpoints
and watchpoints.

show more ...


# 2fc38b2b 16-Mar-2022 Jonas Devlieghere <[email protected]>

[lldb] Report debugger diagnostics as events

Report warnings and errors through events instead of printing directly
the to the debugger's error stream. By using events, IDEs such as Xcode
can report

[lldb] Report debugger diagnostics as events

Report warnings and errors through events instead of printing directly
the to the debugger's error stream. By using events, IDEs such as Xcode
can report these issues in the UI instead of having them show up in the
debugger console.

The new diagnostic events are handled by the default event loop. If a
diagnostic is reported while nobody is listening for the new event
types, it is printed directly to the debugger's error stream.

Differential revision: https://reviews.llvm.org/D121511

show more ...


# 28c878ae 14-Mar-2022 Shafik Yaghmour <[email protected]>

[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB

Applied modernize-use-default-member-init clang-tidy check over LLDB.
It appears in many files we had already switched to in cl

[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB

Applied modernize-use-default-member-init clang-tidy check over LLDB.
It appears in many files we had already switched to in class member init but
never updated the constructors to reflect that. This check is already present in
the lldb/.clang-tidy config.

Differential Revision: https://reviews.llvm.org/D121481

show more ...


Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1
# c34698a8 03-Feb-2022 Pavel Labath <[email protected]>

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
inf

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.

After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.

show more ...


Revision tags: llvmorg-15-init
# a007a6d8 31-Jan-2022 Pavel Labath <[email protected]>

[lldb] Convert "LLDB" log channel to the new API


Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1
# 04cbfa95 02-Nov-2021 Quinn Pham <[email protected]>

[lldb][NFC] Inclusive Language: rename master plan to controlling plan

[NFC] As part of using inclusive language within the llvm project, this patch
renames master plan to controlling plan in lldb.

[lldb][NFC] Inclusive Language: rename master plan to controlling plan

[NFC] As part of using inclusive language within the llvm project, this patch
renames master plan to controlling plan in lldb.

Reviewed By: jingham

Differential Revision: https://reviews.llvm.org/D113019

show more ...


# 13005564 28-Oct-2021 Greg Clayton <[email protected]>

Add unix signal hit counts to the target statistics.

Android and other platforms make wide use of signals when running applications and this can slow down debug sessions. Tracking this statistic can

Add unix signal hit counts to the target statistics.

Android and other platforms make wide use of signals when running applications and this can slow down debug sessions. Tracking this statistic can help us to determine why a debug session is slow.

The new data appears inside each target object and reports the signal hit counts:

"signals": [
{
"SIGSTOP": 1
},
{
"SIGUSR1": 1
}
],

Differential Revision: https://reviews.llvm.org/D112683

show more ...


Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1
# 0a1d80d5 09-Apr-2021 Michał Górny <[email protected]>

[lldb] [gdb-remote client] Support minimal fork/vfork handling

Add a support for handling fork/vfork stops in LLGS client. At this
point, it only sends a detach packet for the newly forked child
(a

[lldb] [gdb-remote client] Support minimal fork/vfork handling

Add a support for handling fork/vfork stops in LLGS client. At this
point, it only sends a detach packet for the newly forked child
(and implicitly resumes the parent).

Differential Revision: https://reviews.llvm.org/D100206

show more ...


# cfb96d84 12-Jun-2021 Jim Ingham <[email protected]>

Convert functions that were returning BreakpointOption * to BreakpointOption &.

This is an NFC cleanup.

Many of the API's that returned BreakpointOptions always returned valid ones.
Internally the

Convert functions that were returning BreakpointOption * to BreakpointOption &.

This is an NFC cleanup.

Many of the API's that returned BreakpointOptions always returned valid ones.
Internally the BreakpointLocations usually have null BreakpointOptions, since they
use their owner's options until an option is set specifically on the location.
So the original code used pointers & unique_ptr everywhere for consistency.
But that made the code hard to reason about from the outside.

This patch changes the code so that everywhere an API is guaranteed to
return a non-null BreakpointOption, it returns it as a reference to make
that clear.

It also changes the Breakpoint to hold a BreakpointOption
member where it previously had a UP. Since we were always filling the UP
in the Breakpoint constructor, having the UP wasn't helping anything.

Differential Revision: https://reviews.llvm.org/D104162

show more ...


# 658f6ed1 01-Jun-2021 Jim Ingham <[email protected]>

Make ignore counts work as "after stop" modifiers so they play nicely with conditions

Previously ignore counts were checked when we stopped to do the sync callback in Breakpoint::ShouldStop. That me

Make ignore counts work as "after stop" modifiers so they play nicely with conditions

Previously ignore counts were checked when we stopped to do the sync callback in Breakpoint::ShouldStop. That meant we would do all the ignore count work even when
there is also a condition says the breakpoint should not stop.

That's wrong, lldb treats breakpoint hits that fail the thread or condition checks as "not having hit the breakpoint". So the ignore count check should happen after
the condition and thread checks in StopInfoBreakpoint::PerformAction.

The one side-effect of doing this is that if you have a breakpoint with a synchronous callback, it will run the synchronous callback before checking the ignore count.
That is probably a good thing, since this was already true of the condition and thread checks, so this removes an odd asymmetry. And breakpoints with sync callbacks
are all internal lldb breakpoints and there's not a really good reason why you would want one of these to use an ignore count (but not a condition or thread check...)

Differential Revision https://reviews.llvm.org/D103217

show more ...


Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1
# 0b697561 09-Nov-2020 Walter Erquinigo <[email protected]>

[trace][intel-pt] Implement trace start and trace stop

This implements the interactive trace start and stop methods.

This diff ended up being much larger than I anticipated because, by doing it, I

[trace][intel-pt] Implement trace start and trace stop

This implements the interactive trace start and stop methods.

This diff ended up being much larger than I anticipated because, by doing it, I found that I had implemented in the beginning many things in a non optimal way. In any case, the code is much better now.

There's a lot of boilerplate code due to the gdb-remote protocol, but the main changes are:

- New tracing packets: jLLDBTraceStop, jLLDBTraceStart, jLLDBTraceGetBinaryData. The gdb-remote packet definitions are quite comprehensive.
- Implementation of the "process trace start|stop" and "thread trace start|stop" commands.
- Implementaiton of an API in Trace.h to interact with live traces.
- Created an IntelPTDecoder for live threads, that use the debugger's stop id as checkpoint for its internal cache.
- Added a functionality to stop the process in case "process tracing" is enabled and a new thread can't traced.
- Added tests

I have some ideas to unify the code paths for post mortem and live threads, but I'll do that in another diff.

Differential Revision: https://reviews.llvm.org/D91679

show more ...


# c8faa8c2 23-Mar-2021 Jim Ingham <[email protected]>

Make the stop-on-sharedlibrary-events setting work.

The StopInfoBreakpoint::PerformAction was overriding the synchronous
breakpoint's ShouldStop report. Fix that and add a test.

This fixes two bug

Make the stop-on-sharedlibrary-events setting work.

The StopInfoBreakpoint::PerformAction was overriding the synchronous
breakpoint's ShouldStop report. Fix that and add a test.

This fixes two bugs in the original submission:
1) Actually generate both dylibs by including the second one in the Makefile
2) Don't ask synchronous callbacks for their opinion on whether to stop
in the async context, that info is taken care of by recording the m_should_stop
on entry to PerformAction.

Differential Revision: https://reviews.llvm.org/D98914

show more ...


# 9d081a7f 19-Mar-2021 Jim Ingham <[email protected]>

Revert "Make the stop-on-sharedlibrary-events setting work."

This reverts commit 9406d43138811ac4dfd0ab31434f65a649bc882e.

I messed up a test, and when I got it right it was failing. The changed l

Revert "Make the stop-on-sharedlibrary-events setting work."

This reverts commit 9406d43138811ac4dfd0ab31434f65a649bc882e.

I messed up a test, and when I got it right it was failing. The changed logic
doesn't work quite right (now the async callback called at sync time is
forcing us to stop. I need to be a little more careful about that.

show more ...


# 9406d431 19-Mar-2021 Jim Ingham <[email protected]>

Make the stop-on-sharedlibrary-events setting work.

We weren't taking into account the "m_should_stop" setting that the
synchronous breakpoint callback had already set when we did PerformAction
in t

Make the stop-on-sharedlibrary-events setting work.

We weren't taking into account the "m_should_stop" setting that the
synchronous breakpoint callback had already set when we did PerformAction
in the StopInfoBreakpoint. So we didn't obey its instructions when it
told us to stop. Fixed that and added some tests both for when we
just have the setting, and when we have the setting AND other breakpoints
at the shared library load notification breakpoint address.

Differential Revision: https://reviews.llvm.org/D98914

show more ...


Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1
# e9264b74 06-Apr-2020 Kazuaki Ishizaki <[email protected]>

[lldb] NFC: Fix trivial typo in comments, documents, and messages

Differential Revision: https://reviews.llvm.org/D77460


Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1
# adcd0268 28-Jan-2020 Benjamin Kramer <[email protected]>

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...


# 80814287 24-Jan-2020 Raphael Isemann <[email protected]>

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73258

show more ...


Revision tags: llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3
# 7049b0ad 15-Aug-2019 Jim Ingham <[email protected]>

Stop-hooks weren't getting called on step-out. Fix that.

There was a little bit of logic in the StopInfoBreakpoint::PerformAction
that would null out the StopInfo once we had a completed plan so tha

Stop-hooks weren't getting called on step-out. Fix that.

There was a little bit of logic in the StopInfoBreakpoint::PerformAction
that would null out the StopInfo once we had a completed plan so that the
next call to GetStopInfo would replace it with the StopInfoThreadPlan.

But the stop-hooks check for whether a thread stopped for a reason didn't
trigger this conversion. So I added an API to do that directly, and then
called it where before we just reset the StopInfo.

<rdar://problem/54270767>

Differential Revision: https://reviews.llvm.org/D66241

llvm-svn: 369052

show more ...


Revision tags: llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1
# 63e5fb76 24-Jul-2019 Jonas Devlieghere <[email protected]>

[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)

This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style for

[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)

This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.

So instead of writing:

if (log)
log->Printf("%s\n", str);

You'd write:

LLDB_LOG(log, "%s\n", str);

This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.

find . -type f -name '*.cpp' -exec \
sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +

Differential revision: https://reviews.llvm.org/D65128

llvm-svn: 366936

show more ...


123456