Summary:
some unwind formats are specific to a single symbol file and so it does
not make sense for their parsing code live in the general Symbol library
(as is the case with eh_frame for instance). This is the case for the
unwind information in breakpad files, but the same will probably be true
for PDB unwind info (once we are able to parse that).
This patch adds the ability to fetch an unwind plan provided by a symbol
file plugin, as discussed in the RFC at
<http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>.
I've kept the set of changes to a minimum, as there is no way to test
them until we have a symbol file which implements this API -- that is
comming in a follow-up patch, which will also implicitly test this
change.
The interesting part here is the introduction of the
"RegisterInfoResolver" interface. The reason for this is that breakpad
needs to be able to resolve register names (which are present as strings
in the file) into register enums so that it can construct the unwind
plan. This is normally done via the RegisterContext class, handing this
over to the SymbolFile plugin would mean that it has full access to the
debugged process, which is not something we want it to have. So instead,
I create a facade, which only provides the ability to query register
names, and hide the RegisterContext behind the facade.
Also note that this only adds the ability to dump the unwind plan
created by the symbol file plugin -- the plan is not used for unwinding
yet -- this will be added in a third patch, which will add additional
tests which makes sure the unwinding works as a whole.
Reviewers: jasonmolenda, clayborg
Subscribers: markmentovai, amccarth, lldb-commits
Differential Revision: https://reviews.llvm.org/D61732
llvm-svn: 360409
In r359354 a GetDebugger() method was added to the CommandObject class,
so that we didn't have to go through the command interpreter to obtain
the script interpreter. This patch simplifies other call sites where
m_interpreter.GetDebugger() was used, and replaces them with a shorter
call to the new method.
llvm-svn: 359373
Before a Debugger gets a Target, target settings are routed to a global set
of settings. Even without this, some part of the LLDB which exist independently
of the Debugger object (the Module cache, the Symbol vendors, ...) access
directly the global default store for those settings.
Of course, if you modify one of those global settings while they are being read,
bad things happen. We see this quite a bit with FileSpecList settings. In
particular, we see many cases where one debug session changes
target.exec-search-paths while another session starts up and it crashes when
one of those accesses invalid FileSpecs.
This patch addresses the specific FileSpecList issue by adding locking to
OptionValueFileSpecList and never returning by reference.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60468
llvm-svn: 359028
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
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
Add a flag to control whether the ModulesDidLoad notification is
called when a module is added. If the notifications are disabled,
the caller must call ModulesDidLoad after adding all the new modules,
but postponing this notification until they're all batched up can
allow for better efficiency than notifying one-by-one.
Change the name of the ModuleList notifier functions that a subclass
can implement to start with 'Notify' to make it clear what they are.
Add a NotifyModulesRemoved.
Add header documentation for the changed/updated methods.
Added defaulted-value 'notify' argument to ModuleList Append,
AppendIfNeeded, and Remove because callers working with a local
ModuleList don't have an obvious idea of what notify means in this
context. When the ModuleList is a part of the Target class, the
notify behavior matters.
DynamicLoaderDarwin has been updated so that libraries being
added/removed are correctly batched up before notifications are
sent. Added the TestModuleLoadedNotifys.py test to run on
Darwin to test this.
<rdar://problem/48293064>
Differential Revision: https://reviews.llvm.org/D60172
llvm-svn: 357955
Summary:
Within .lldbinit, regex commands can be structured as a list of substitutions over
multiple lines. It's possible that this is uninentional, but it works and has
benefits.
For example:
command regex <command-name>
s/pat1/repl1/
s/pat2/repl2/
...
I use this form of `command regex` in my `~/.lldbinit`, because it makes it
clearer to write and read compared to a single line definition, because
multiline substitutions don't need to be quoted, and are broken up one per line.
However, multiline definitions result in usage instructions being printed for
each use. The result is that every time I run `lldb`, I get a dozen or more
lines of noise. With this change, the instructions are only printed when
`command regex` is invoked interactively, or from a terminal, neither of which
are true when lldb is sourcing `~/.lldbinit`.
Reviewers: clayborg, jingham
Reviewed By: clayborg
Subscribers: jdoerfert, kastiglione, xiaobai, keith, lldb-commits
Differential Revision: https://reviews.llvm.org/D48752
llvm-svn: 355793
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
Given that we have a target named Symbols, one wonders why a
file named Symbols.cpp is not in this target. To be clear,
the functions exposed from this file are really focused on
*locating* a symbol file on a given host, which is where the
ambiguity comes in. However, it makes more sense conceptually
to be in the Symbols target. While some of the specific places
to search for symbol files might change depending on the Host,
this is not inherently true in the same way that, for example,
"accessing the file system" or "starting threads" is
fundamentally dependent on the Host.
PDBs, for example, recently became a reality on non-Windows platforms,
and it's theoretically possible that DSYMs could become a thing on non
MacOSX platforms (maybe in a remote debugging scenario). Other types of
symbol files, such as DWO, DWP, etc have never been tied to any Host
platform anyway.
After this patch, there is only one remaining dependency from
Host to Target.
Differential Revision: https://reviews.llvm.org/D58730
llvm-svn: 355032
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
Summary:
This is a preparatory step to enable adding extra unwind strategies by
symbol file plugins. This has been discussed on the lldb-dev mailing
list: <http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>.
Reviewers: jasonmolenda, clayborg, espindola
Subscribers: lemo, emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D58129
llvm-svn: 354033
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
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
This reapplies r350802, which was reverted because of issues with
parsing posix-style paths on windows hosts (and vice-versa). These have
since been fixed in r351328, and lldb should now recognise the path
style used in a dwarf compile unit correctly.
llvm-svn: 351435
This parameter was only ever used with the Module set, and
since a SymbolFile is tied to a module, the parameter turns
out to be entirely unnecessary. Furthermore, it doesn't make
a lot of sense to ask a caller to ask SymbolFile which is tied
to Module X to find types for Module Y, but that possibility
was open with the previous interface. By removing this
parameter from the API, it makes it harder to use incorrectly
as well as easier for an implementor to understand what it
needs to do.
llvm-svn: 351133
This reverts commit r350802 because the test fails on windows. This
happens because we treat the paths as windows paths even though they
have linux path separators in the asm file. That results in wrong paths
being computed (\tmp\tmp\a.c instead of /tmp/a.c).
Reverting until I can figure out what to do with this.
llvm-svn: 350810
Summary:
The motivation for this is being able to write tests for the upcoming
breakpad line table parser, but this could be useful for testing the
low-level workings of any line table format. Or simply for viewing the
line table information with more detail (the brief format doesn't
include any of the flags for end_of_prologue and similar).
I've also removed the load_addresses argument from the
DumpCompileUnitLineTable function, as it wasn't being used anywhere.
Reviewers: clayborg, zturner
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56315
llvm-svn: 350802
Summary:
This function was named such because in the case of MachO files, the
mach header is located at this address. However all (most?) usages of
this function were not interested in that fact, but the fact that this
address is used as the base address for expressing various relative
addresses in the object file.
For other object file formats, this name is not appropriate (and it's
probably the reason why this function was not implemented in these
classes). In the ELF case the ELF header will usually end up at this
address, but this is a result of the linker optimizing the file layout
and not a requirement of the spec. For COFF files, I believe the is no
header located at this address either.
Reviewers: clayborg, jasonmolenda, amccarth, lemo, stella.stamenova
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55422
llvm-svn: 348849
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 is useful for investigating the clang ast as you reconstruct
it via by parsing debug info. It can also be used to write tests
against.
Differential Revision: https://reviews.llvm.org/D54072
llvm-svn: 346149
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 patch removes the GetPermissions and GetReadable methods from
FileSpec and updates its uses with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53831
llvm-svn: 345843
Jonas Devlieghere
Pavel Labath
Frederic Riss
Jason Molenda
Dave Lee
Jim Ingham
Zachary Turner
Chandler Carruth