Some functions in this file only use the "target" component of an
execution context. Adjust the argument lists to reflect that.
This avoids some defensive null checks and simplifies most of the
callers.
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
I previously removed the code in ValueObject::GetExpressionPath that
took advantage of the parameter `qualify_cxx_base_classes`. As a result,
this is now unused and can be removed.
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
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
If you don't do this you end up running arbitrary code with
only one thread allowed to run, which can cause deadlocks.
<rdar://problem/56422478>
Differential Revision: https://reviews.llvm.org/D71440
Summary:
This patch factors out File as an abstract base
class and moves most of its actual functionality into
a subclass called NativeFile. In the next patch,
I'm going to be adding subclasses of File that
don't necessarily have any connection to actual OS files,
so they will not inherit from NativeFile.
This patch was split out as a prerequisite for
https://reviews.llvm.org/D68188
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68317
llvm-svn: 373564
It is always doing work on behalf of another thread that presumably
has the mutex, so if it is calling SB API's it should have free access
to the mutex. This is the same decision as we made earlier with the
process RunLock.
Differential Revision: https://reviews.llvm.org/D68174
llvm-svn: 373280
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
lvm_private::File::GetStream() can fail if m_options == 0
It's not clear from the header a File created with a descriptor will be
not be usable by many parts of LLDB unless SetOptions is also called,
but it is.
This is because those parts of LLDB rely on GetStream() to use the
file, and that in turn relies on calling fdopen on the descriptor. When
calling fdopen, GetStream relies on m_options to determine the access
mode. If m_options has never been set, GetStream() will fail.
This patch adds options as a required argument to File::SetDescriptor
and the corresponding constructor.
Patch by: Lawrence D'Anna
Differential revision: https://reviews.llvm.org/D67792
llvm-svn: 372652
Summary:
InferiorCall is only ever used in Process, and it is not specific to
POSIX. By moving it to Process, we can remove all dependencies on plugins from
Process. Moving InferiorCall to Process seems to achieve this quite well.
Additionally, the name InferiorCall is a little vague now, so we rename
it something a bit more specific.
Reviewers: JDevlieghere, clayborg, compnerd, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67472
llvm-svn: 371796
Remove the single instance of std::call_once() in lldbTarget library
with llvm::call_once(). The former fails to build on NetBSD when
combined with llvm::once_flag (which replaced std::once_flag
in r369618), and combining the two is probably generally incorrect
anyway.
llvm-svn: 370748
This function is not portable, and there are only a handful of usages of
it anyway. Replacing it with std::this_thread::sleep_for enables us to
get rid of the compatibility code in PosixApi.h.
llvm-svn: 367814
Summary:
This is a bit more explicit, and makes it possible to build LLDB without
varying the -I lines per-directory.
(The latter is useful because many build systems only allow this to be
configured per-library, and LLDB is insufficiently layered to be split into
multiple libraries on stricter build systems).
(My comment on D65185 has some more context)
Reviewers: JDevlieghere, labath, chandlerc, jdoerfert
Reviewed By: labath
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65397
Patch by Sam McCall!
llvm-svn: 367241
Right now our Properties.inc only generates the initializer for the
options list but not the array declaration boilerplate around it. As the
array definition is identical for all arrays, we might as well also let
the Properties.inc generate it alongside the initializers.
Unfortunately we cannot do the same for enums, as there's this magic
ePropertyExperimental, which needs to come at the end to be interpreted
correctly. Hopefully we can get rid of this in the future and do the
same for the property enums.
Differential revision: https://reviews.llvm.org/D65353
llvm-svn: 367238
Property definitions are currently defined in a PropertyDefinition array
and have a corresponding enum to index in this array. Unfortunately this
is quite error prone. Indeed, just today we found an incorrect merge
where a discrepancy between the order of the enum values and their
definition caused the test suite to fail spectacularly.
Tablegen can streamline the process of generating the property
definition table while at the same time guaranteeing that the enums stay
in sync. That's exactly what this patch does. It adds a new tablegen
file for the properties, building on top of the infrastructure that
Raphael added recently for the command options. It also introduces two
new tablegen backends: one for the property definitions and one for
their corresponding enums.
It might be worth mentioning that I generated most of the tablegen
definitions from the existing property definitions, by adding a dump
method to the struct. This seems both more efficient and less error
prone that copying everything over by hand. Only Enum properties needed
manual fixup for the EnumValues and DefaultEnumValue fields.
Differential revision: https://reviews.llvm.org/D65185
llvm-svn: 367058
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
Summary:
IRDynamicChecks in its current form is specific to Clang since it deals
with the C language family. It is possible that we may want to
instrument code generated for other languages, but we can factor in a
more general mechanism to do so at a later time.
This decouples ObCLanguageRuntime from Expression!
Reviewers: compnerd, clayborg, jingham, JDevlieghere
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D64591
llvm-svn: 365853
Change the interface to return an expected, instead of taking a Status
pointer.
Differential revision: https://reviews.llvm.org/D64163
llvm-svn: 365226
on a thread. When talking to some older gdb-remote stubs, We were getting
a stop reason from the stop reply packet and setting it on the relevant
thread before we updated the full stop list. That would get discarded when
the full list was updated.
Also, if you already have a thread list when you go to see if there is an
Operating System plugin, and you do indeed load a new OS plugin, you have to
re-fetch the thread list or it will only show the raw threads.
Differential Revision: https://reviews.llvm.org/D62887
llvm-svn: 364666
Summary:
If target.preload-symbols is false, waiting for the process to "stop"
can take an arbitrarily long amount of time, because it will cause all
the debug info to be parsed (to compute the stop message showing the
function, its arguments, etc).
We were previously waiting for 10 seconds for the stop even to arrive,
which is a pretty long time, but it's not that hard to overcome with
huge debug info.
Since any arbitrary limit can be theoretically overcome with huge
debug_info and/or slow machine, and the stop even was sent 3 lines above
the wait, if we ever do not receive the stop even means we've got a bug
in lldb. Therefore, I remove the timeout on this wait completely.
No test because I don't know how to reproduce this without a
multi-gigabyte symbol file.
Reviewers: jingham, clayborg
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D63730
llvm-svn: 364276
Summary:
This is the second patch to improve module loading in a series that started here (where I explain the motivation and solution): https://reviews.llvm.org/D62499
I need to read the aux vector to know where the r_debug map with the loaded libraries are.
The AuxVector class was made generic so it could be reused between the POSIX-DYLD plugin and NativeProcess*. The class itself ended up in the ProcessUtility plugin.
Reviewers: clayborg, xiaobai, labath, JDevlieghere
Reviewed By: clayborg, labath, JDevlieghere
Subscribers: emaste, JDevlieghere, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62500
llvm-svn: 363098
Summary:
In an effort to make Process more language agnostic, I removed
GetCPPLanguageRuntime from Process. I'm following up now with an equivalent
change for ObjC.
Differential Revision: https://reviews.llvm.org/D63052
llvm-svn: 362981
Summary:
Using llvm-style rtti gives us stronger guarantees around casting
LanguageRuntimes.
As discussed in D62755
Differential Revision: https://reviews.llvm.org/D62934
llvm-svn: 362884
Summary:
I want to remove this method because I think that Process should be
language agnostic, or at least, not have knowledge about specific language
runtimes. There is "GetLanguageRuntime()" which should be used instead. If the
caller a CPPLanguageRuntime, they should cast it as needed. Ideally, this
should only happen in plugins that need C++ specific knowledge.
The next step I would like to do is remove "GetObjCLanguageRuntime()" as well.
There are a lot more instances of that function being used, so I wanted to
upload this one first to get the general reception to this idea.
Reviewers: compnerd, davide, JDevlieghere, jingham, clayborg, labath, aprantl
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D62755
llvm-svn: 362544
Summary:
Currently there's not really a good way to iterate over the language runtimes a
process has. This is sometimes desirable (as seen in my change to Thread).
Additionally, there's not really a good reason to iterate over every available
language, but rather only over languages for which we have a plugin loaded.
Reviewers: JDevlieghere, davide, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D62562
llvm-svn: 361999
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
Summary:
From what I understand, it's possible for multiple threads to request
a specific language runtime (e.g. CPPLanguageRuntime). This leads to a data
race.
Reviewers: jingham, JDevlieghere, compnerd, clayborg
Differential Revision: https://reviews.llvm.org/D62169
llvm-svn: 361442
Currently when we single step over a source line, we run and stop at every branch in the source line range. We can reduce the number of times we stop when stepping over by figuring out if any of these branches are function calls, and if so, ignore these branches. Since we are stepping over we can safely ignore these calls since they will return to the next instruction. Currently the step logic would stop at those branches (1st stop), single step into the branch (2nd stop), and then set a breakpoint at the return address (3rd stop), and then continue.
Differential Revision: https://reviews.llvm.org/D58678
llvm-svn: 360375
A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.
Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.
I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.
Differential revision: https://reviews.llvm.org/D60508
llvm-svn: 358135
Since these timeouts guard against catastrophic error in debugserver,
I also increased all of them to the maximum value among them.
The motivation for this test was the observation that an asanified
LLDB would often exhibit seemingly random test failures that could be
traced back to debugserver packets getting out of sync. With this path
applied I can no longer reproduce the one particular failure mode that
I was investigating.
rdar://problem/49441261
Differential Revision: https://reviews.llvm.org/D60340
llvm-svn: 357829
I found the code of Process::WriteMemory particularly hard to follow
when reviewing Ismail's change in D60022. This simplifies the code and
hopefully prevents similar oversights in the future.
Differential revision: https://reviews.llvm.org/D60092
llvm-svn: 357428
Summary:
In case of a breakpoint site overlapping with the destination address,
the WriteMemory method reported an incorrect memory size.
Instead of returning the right amount of bytes written, it falls through
the scope and returned 0.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Reviewers: jasonmolenda, friss, jingham
Subscribers: JDevlieghere, davide, lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60022
llvm-svn: 357420
Previously if an invalid program was specified, there was a bug
which, when we attempted to launch the program, would report that
the operation succeeded, causing LLDB to then hang while waiting
indefinitely to receive some events from the process.
After this patch, when an invalid program is specified, we immediately
return to vs code with an error message that indicates that the
program can not be found.
Differential Revision: https://reviews.llvm.org/D59114
llvm-svn: 355656
My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.
ConstString has exactly one const char * data member, so passing a
ConstString by reference is not any more efficient than copying it by
value. In both cases a single pointer is passed. But passing it by
value makes it harder to accidentally return the address of a local
object.
(This fixes rdar://problem/48640859 for the Apple folks)
Differential Revision: https://reviews.llvm.org/D59030
llvm-svn: 355553
There are set of classes in Target that describe the parameters of a
process - e.g. it's PID, name, user id, and similar. However, since it
is a bare description of a process and contains no actual functionality,
there's nothing specifically that makes this appropriate for being in
Target -- it could just as well be describing a process on the host, or
some hypothetical virtual process that doesn't even exist.
To cement this, I'm moving these classes to Utility. It's possible that
we can find a better place for it in the future, but as it is neither
Host specific nor Target specific, Utility seems like the most appropriate
place for the time being.
After this there is only 2 remaining references to Target from Host,
which I'll address in a followup.
Differential Revision: https://reviews.llvm.org/D58842
llvm-svn: 355342
Summary:
This creates an abstract base class called "UserIDResolver", which can
be implemented to provide user/group ID resolution capabilities for
various objects. Posix host implement a PosixUserIDResolver, which does
that using posix apis (getpwuid and friends). PlatformGDBRemote
forwards queries over the gdb-remote link, etc. ProcessInstanceInfo
class is refactored to make use of this interface instead of taking a
platform pointer as an argument. The base resolver class already
implements caching and thread-safety, so implementations don't have to
worry about that.
The main motivating factor for this was to remove external dependencies
from the ProcessInstanceInfo class (so it can be put next to
ProcessLaunchInfo and friends), but it has other benefits too:
- ability to test the user name caching code
- ability to test ProcessInstanceInfo dumping code
- consistent interface for user/group resolution between Platform and
Host classes.
Reviewers: zturner, clayborg, jingham
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D58167
llvm-svn: 355323
When the debugger is run in sync mode, you need to
be able to tell whether a hijacked resume is for some
special purpose (like waiting for the SIGSTOP on attach)
or just to perform a synchronous resume. Target::Launch was doing
that wrong, and that caused stop-hooks on process launch
in source files to behave incorrectly.
<rdar://problem/48115661>
Differential Revision: https://reviews.llvm.org/D58727
llvm-svn: 355213
They aren't designed to nest recursively, so this will prevent that.
Also add a --auto-continue flag, putting "continue" in the stop hook makes
the stop hooks fight one another in multi-threaded programs.
Also allow more than one -o options so you can make more complex stop hooks w/o
having to go into the editor.
<rdar://problem/48115661>
Differential Revision: https://reviews.llvm.org/D58394
llvm-svn: 354706
The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.
In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.
I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.
llvm-svn: 353912
Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared to ::reset(new), it also performs a single
heap allocation for the object and control block.
Differential revision: https://reviews.llvm.org/D57990
llvm-svn: 353764
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Summary:
These are general purpose "utility" classes, whose functionality is not
debugger-specific in any way. As such, I believe they belong in the
Utility module.
This doesn't break any particular dependency (yet), but it reduces the
number of Core dependencies across the board.
Reviewers: zturner, jingham, teemperor, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D55361
llvm-svn: 349157
When debugging read-only memory we cannot use software breakpoint. We
already have support for hardware breakpoints and users can specify them
with `-H`. However, there's no option to force LLDB to use hardware
breakpoints internally, for example while stepping.
This patch adds a setting target.require-hardware-breakpoint that forces
LLDB to always use hardware breakpoints. Because hardware breakpoints
are a limited resource and can fail to resolve, this patch also extends
error handling in thread plans, where breakpoints are used for stepping.
Differential revision: https://reviews.llvm.org/D54221
llvm-svn: 346920
This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
llvm-svn: 346626
This patch removes the logic for resolving paths out of FileSpec and
updates call sites to rely on the FileSystem class instead.
Differential revision: https://reviews.llvm.org/D53915
llvm-svn: 345890
This patch removes the Exists method from FileSpec and updates its uses
with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53845
llvm-svn: 345854
This is an NFC commit to refactor the "load dependent files" parameter
from a boolean to an enum value. We want to be able to specify a
default, in which case we decide whether or not to load the dependent
files based on whether the target is an executable or not (i.e. a
dylib).
This is a dependency for D51934.
Differential revision: https://reviews.llvm.org/D51859
llvm-svn: 342633
Summary:
D48465 is currently blocked by the fact that tab-completing the first expression is deadlocking LLDB.
The reason for this deadlock is that when we push the ProcessIO handler for reading the Objective-C runtime
information from the executable (which is triggered when we parse the an expression for the first time),
the IOHandler can't be pushed as the Editline::Cancel method is deadlocking.
The deadlock in Editline is coming from the m_output_mutex, which is locked before we go into tab completion.
Even without this lock, calling Cancel on Editline will mean that Editline cleans up behind itself and deletes the
current user-input, which is screws up the console when we are tab-completing at the same time.
I think for now the most reasonable way of fixing this is to just not call Cancel on the current IOHandler when we push
the IOHandler for running an internal utility function.
As we can't really write unit tests for IOHandler itself (due to the hard dependency on an initialized Debugger including
all its global state) and Editline completion is currently also not really testable in an automatic fashion, the test for this has
to be that the expression command completion in D48465 doesn't fail when requesting completion the first time.
A more precise test plan for this is:
1. Apply D48465.
2. Start lldb and break in some function.
3. Type `expr foo` and press tab to request completion.
4. Without this patch, we deadlock and LLDB stops responding.
I'll provide an actual unit test for this once I got around and made the IOHandler code testable,
but for now unblocking D48465 is more critical.
Thanks to Jim for helping me debugging this.
Reviewers: jingham
Reviewed By: jingham
Subscribers: emaste, clayborg, abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D50912
llvm-svn: 340988
This change improves the logging for the lldb.module category to note a few interesting cases:
1. Local object file found, but specs not matching
2. Local object file not found, using a placeholder module
The handling and logging for the cases wehre we fail to load compressed dwarf
symbols is also improved.
Differential Revision: https://reviews.llvm.org/D50274
llvm-svn: 339161
These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall code layering (although it still does not break any particular
dependency completely).
The XCode project will need to be updated after this change.
Differential Revision: https://reviews.llvm.org/D49740
llvm-svn: 339127
Summary:
Occasionally, when launching a process in lldb (especially on windows, but not limited to), lldb will hang before the process is launched and it will never recover. This happens because the timing of the processing of the state changes can be slightly different. The state changes that are issued are:
1) SetPublicState(eStateLaunching)
2) SetPrivateState(eStateLaunching)
3) SetPublicState(eStateStopped)
4) SetPrivateState(eStateStopped)
What we expect to see is:
public state: launching -> launching -> stopped
private state: launching -> stopped
What we see is:
public state: launching -> stopped -> launching
private state: launching -> stopped
The second launching change to the public state is issued when WaitForProcessStopPrivate calls HandlePrivateEvent on the event which was created when the private state was set to launching. HandlePrivateEvent has logic to determine whether to broadcase the event and a launching event is *always* broadcast. At the same time, when the stopped event is processed by WaitForProcessStopPrivate next, the function exists and that event is never broadcast, so the public state remains as launching.
HandlePrivateEvent does two things: determine whether there's a next action as well as determine whether to broadcast the event that was processed. There's only ever a next action set if we are trying to attach to a process, but WaitForProcessStopPrivate is only ever called when we are launching a process or connecting remotely, so the first part of HandlePrivateEvent (handling the next action) is irrelevant for WaitForProcessStopPrivate. As far as broadcasting the event is concerned, since we are handling state changes that already occurred to the public state (and are now duplicated in the private state), I believe the broadcast step is unnecessary also (and in fact, it causes the hang).
This change removes the call to HandlePrivateEvent from inside WaitForProcessStopPrivate.
Incidentally, there was also a bug filed recently that is the same issue: https://bugs.llvm.org/show_bug.cgi?id=37496
Reviewers: asmith, labath, zturner, jingham
Reviewed By: zturner, jingham
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47609
llvm-svn: 333781
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
Summary:
Multiple threads could be calling into DoLoadImage concurrently,
only one should be allowed to create the UtilityFunction.
Reviewers: jingham
Subscribers: emaste, lldb-commits
Differential Revision: https://reviews.llvm.org/D46733
llvm-svn: 332115
Summary:
The comments on this class were out of date with the implementation, and
the implementation itself was inconsistent with our usage of the Timeout
class (I started converting everything to use this class back in D27136,
but I missed this one). I avoid duplicating the waiting logic by
introducing a templated WaitFor function, and make other functions
delegate to that. This function can be also used as a replacement for
the unused WaitForBitToBeSet functions I removed, if it turns out to be
necessary.
As this changes the meaning of a "zero" timeout, I tracked down all the
callers of these functions and updated them accordingly. Propagating the
changes to all the callers of RunShellCommand was a bit too much for
this patch, so I stopped there and will continue that in a follow-up
patch.
I also add some basic unittests for the functions I modified.
Reviewers: jingham, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D46580
llvm-svn: 331880
The function can only return in one of two ways: the Predicate value is
successfully set within the allotted time, or it isn't (the wait times
out). These states can be represented in the return value, and the extra
arg adds no value.
llvm-svn: 331458
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
That way we won't have to compile a new expression every time we want
dlopen a library.
<rdar://problem/32626584>
Differential Revision: https://reviews.llvm.org/D45703
llvm-svn: 330214
Summary:
The idea behind this is to move the functionality which depend on other lldb
classes into a separate class. This way, the Args class can be turned
into a lightweight arc+argv wrapper and moved into the lower lldb
layers.
Reviewers: jingham, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D44306
llvm-svn: 329677
The difference between this and the previous patch is that now we use
ELF physical addresses only for loading objects into the target (and the
rest of the module load address logic still uses virtual addresses).
Summary:
When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup.
- Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address.
- Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications
- Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region
Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: llvm-commits, arichardson, emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42145
Patch by Owen Shaw <llvm@owenpshaw.net>.
llvm-svn: 327970
The OS plugins might have updated the thread list after a core file has
been loaded. The physical thread in the core file may no longer be the
one that should be selected. Hence we should run the thread selection
logic after loading the core.
Differential revision: https://reviews.llvm.org/D44139
llvm-svn: 327501
This reverts commit r326261 as it introduces inconsistencies in the
handling of load addresses for ObjectFileELF -- some parts of the class
use physical addresses, and some use virtual. This has manifested itself
as us not being able to set the load address of the vdso "module" on
android.
llvm-svn: 326367
Summary:
When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup.
- Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address.
- Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications
- Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region
Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: arichardson, emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42145
Patch by Owen Shaw <llvm@owenpshaw.net>
llvm-svn: 326261
Summary:
There was some confusion in the code about how to represent process
environment. Most of the code (ab)used the Args class for this purpose,
but some of it used a more basic StringList class instead. In either
case, the fact that the underlying abstraction did not provide primitive
operations for the typical environment operations meant that even a
simple operation like checking for an environment variable value was
several lines of code.
This patch adds a separate Environment class, which is essentialy a
llvm::StringMap<std::string> in disguise. To standard StringMap
functionality, it adds a couple of new functions, which are specific to
the environment use case:
- (most important) envp conversion for passing into execve() and likes.
Instead of trying to maintain a constantly up-to-date envp view, it
provides a function which creates a envp view on demand, with the
expectation that this will be called as the very last thing before
handing the value to the system function.
- insert(StringRef KeyEqValue) - splits KeyEqValue into (key, value)
pair and inserts it into the environment map.
- compose(value_type KeyValue) - takes a map entry and converts in back
into "KEY=VALUE" representation.
With this interface most of the environment-manipulating code becomes
one-liners. The only tricky part was maintaining compatibility in
SBLaunchInfo, which expects that the environment entries are accessible
by index and that the returned const char* is backed by the launch info
object (random access into maps is hard and the map stores the entry in
a deconstructed form, so we cannot just return a .c_str() value). To
solve this, I have the SBLaunchInfo convert the environment into the
"envp" form, and use it to answer the environment queries. Extra code is
added to make sure the envp version is always in sync.
(This also improves the layering situation as Args was in the Interpreter module
whereas Environment is in Utility.)
Reviewers: zturner, davide, jingham, clayborg
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D41359
llvm-svn: 322174
Also add a test. There should also be control for this
in ProcessLaunchInfo and a "target launch" flag, but at least
this will allow you to control it somehow.
<rdar://problem/35842137>
llvm-svn: 319731
Summary:
ArchSpec::SetTriple was taking a Platform as an argument, and used it to
fill in missing pieces of the specified triple. I invert the dependency
by moving this code to other classes. For this purpose, I've created
three new functions.
- HostInfo::GetAugmentedArchSpec: fills in the triple using the host
platform (this used to be implemented by passing a null platform
pointer). By putting this code in the Host module, we can provide a
way to anyone who does not have a platform instance (lldb-server) an
easy way to get Host data.
- Platform::GetAugmentedArchSpec: if you have a platform instance, you
can call this to let it fill in the triple.
- static Platform::GetAugmentedArchSpec: implements the "if platform ==
0 then use_host() else use_platform()" part.
Reviewers: zturner, jingham, clayborg
Subscribers: mgorny, javed.absar, lldb-commits
Differential Revision: https://reviews.llvm.org/D39387
llvm-svn: 316987
This creates a new Architecture plugin and moves the stop info override
callback to this place. The motivation for this is to remove complex
dependencies from the ArchSpec class because it is used in a lot of
places that (should) know nothing about Process instances and StopInfo
objects.
I also add a test for the functionality covered by the override
callback.
Differential Revision: https://reviews.llvm.org/D31172
llvm-svn: 316609
The main change is to avoid setting the process state as running when
debugging core/minidumps (details in the bug). Also included a few small,
related fixes around how the errors propagate in this case.
Fixed the FreeBSD/Windows break: the intention was to keep
Process::WillResume() and Process::DoResume() "in-sync", but this had the
unfortunate consequence of breaking Process sub-classes which don't override
WillResume().
The safer approach is to keep Process::WillResume() untouched and only
override it in the minidump and core implementations.
patch by lemo
Bug: https://bugs.llvm.org/show_bug.cgi?id=34532
Differential Revision: https://reviews.llvm.org/D37651
llvm-svn: 313655
The main change is to avoid setting the process state as running when
debugging core/minidumps (details in the bug).
Also included a few small, related fixes around how the errors propagate in
this case.
patch by lemo
Bug: https://bugs.llvm.org/show_bug.cgi?id=34532
Differential Revision: https://reviews.llvm.org/D37651
llvm-svn: 313210
some methods in the ABI need a Process to do their work.
Instead of passing it in as a one-off argument to those
methods, this patch puts it in the base class and the methods
can retrieve if it needed.
Note that ABI's are sometimes built without a Process
(e.g. SBTarget::GetStackRedZoneSize) so it's entirely
possible that the process weak pointer will not be
able to reconsistitue into a strong pointer.
<rdar://problem/32526754>
llvm-svn: 306633
This is a resubmit of r303732, which was reverted due to a regression.
The original patch caused a regression in TestLoadUnload, which has only showed
up when running the remote test suite. The problem there was that we interrupted
the target just as it has hit the rendezvous breakpoint in the dlopen call. This
meant that the stop reason was set to "breakpoint" even though the event would
not have been broadcast if we had not stopped the process. I fix this by
checking StopInfo->ShouldNotify() before stopping.
I also add a new test for the handling of conditional breakpoints in
expressions, which I noticed to be broken (pr33164)
Differential Revision: https://reviews.llvm.org/D33283
llvm-svn: 303848
Summary:
The function had logic to handle the case when the expression terminated
while we were trying to halt the process, but it failed to take into
account the possibility that the expression stopped because it hit a
breakpoint. This was caused by the fact that the handling of the stopped
events was duplicated for the "halting" and regular cases (the regular
case handled this situation correctly). I've tried to merge these two
cases into one to make sure they stay in sync.
I should call out that the two cases were checking whether the thread
plan has completed in slightly different ways. I am not sure what is the
difference between them, but I think the check should be the same in
both cases, whatever it is, so I just took the one from the regular
case, as that is probably more tested.
For the test, I modified TestUnwindExpression to run the expression with
a smaller timeout (this is how I found this bug originally). With a 1ms
one thread timeout, the test failed consistently without this patch.
Reviewers: jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D33283
llvm-svn: 303732
It was returning const std::string& which was leading to
unnecessary copies all over the place, and preventing people
from doing things like Dict->GetValueForKeyAsString("foo", ref);
llvm-svn: 302875
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.
llvm-svn: 302872
Jonas Devlieghere