This is a step towards making the initialize and terminate calls be
generated by CMake, which in turn is towards making it possible to
disable plugins at configuration time.
Differential revision: https://reviews.llvm.org/D74245
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
These are the last sections not managed by the DWARFContext object. I
also introduce separate SectionType enums for dwo section variants, as
this is necessary for proper handling of single-file split dwarf.
This error message didn't specify which file was malformed, so
there's some hunting-around required if it comes up. We have the
filename; include it in the error message.
Remove the hack that populates the cpsr register in the gpr struct by
writing past the end of the array. This was tripping up ASan.
Patch by: Reva Cuthbertson
This patch removes the size_t return value and the append parameter
from the remainder of the Find.* functions in LLDB's internal API. As
in the previous patches, this is motivated by the fact that these
parameters aren't really used, and in the case of the append parameter
were frequently implemented incorrectly.
Differential Revision: https://reviews.llvm.org/D69119
llvm-svn: 375160
This makes parsing the symbol table of clang marginally faster. (Hashtable versus tree).
Differential Revision: https://reviews.llvm.org/D68605
llvm-svn: 374084
The symtab parser in ObjectFileMachO has logic to coalesce debug (STAB)
and non-debug symbols, based on the address and the symbol name for
static (STSYM) and global symbols (GSYM) respectively. It makes the
assumption that the debug variant is always encountered first. Rather
than creating a second entry in the symbol table for the non-debug
symbol, the latter gets merged into the existing debug symbol.
This breaks when the linker emits the non-debug symbol first. We'd end
up with two entries in the symbol table, each containing part of the
information LLDB relies on. Indeed, commenting out the merging logic
breaks the test suite spectacularly.
This patch solves that problem by always parsing the debug symbols
first. This guarantees that the assumption for merging holds.
I'm not particularly happy with adding a lambda, but after numerous
attempts this is the best solution I could come up with. The symtab
parsing logic is pretty complex in that it touches a lot of things. I've
experienced first hand that it's very easy to break things. I believe
this approach strikes a balance between fixing the issue while limiting
the risk of regressions.
Differential revision: https://reviews.llvm.org/D68536
llvm-svn: 373994
This file really suffered from the Great Reformat. I'm adding a few
early returns to give the deeply nested code some more breathing room.
llvm-svn: 373778
Summary:
This patch converts FileSystem::Open from this prototype:
Status
Open(File &File, const FileSpec &file_spec, ...);
to this one:
llvm::Expected<std::unique_ptr<File>>
Open(const FileSpec &file_spec, ...);
This is beneficial on its own, as llvm::Expected is a more modern
and recommended error type than Status. It is also a necessary step
towards https://reviews.llvm.org/D67891, and further developments
for lldb_private::File.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67996
llvm-svn: 373003
The function had the same name as one of the member function, so
it was just copied to all classes so that the lookup works. We
could also give the function a more better and unique name
(because it's actually printing the register value and writing
to the stream, not writing to the register).
Also removes the unused return value.
llvm-svn: 370854
On macOS one Mach-O slice can contain multiple load commands: One load
command for being loaded into a macOS process and one load command for
being loaded into a macCatalyst process. This patch adds support for
the new load command and makes sure ObjectFileMachO returns the
Architecture that matches the Module.
Differential Revision: https://reviews.llvm.org/D66626
llvm-svn: 369814
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368933
Summary:
On the heels of D62934, this patch uses the same approach to introduce
llvm RTTI support to the ObjectFile hierarchy. It also replaces the
existing uses of GetPluginName doing run-time type checks with
llvm::dyn_cast and friends.
This formally introduces new dependencies from some other plugins to
ObjectFile plugins. However, I believe this is fine because:
- these dependencies were already kind of there, and the only reason
we could get away with not modeling them explicitly was because the
code was relying on magically knowing what will GetPluginName() return
for a particular kind of object files.
- the dependencies themselves are logical (it makes sense for
SymbolVendorELF to depend on ObjectFileELF), or at least don't
actively get in the way (the JitLoaderGDB->MachO thing).
- they don't introduce any new dependency loops as ObjectFile plugins
don't depend on any other plugins
Reviewers: xiaobai, JDevlieghere, espindola
Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65450
llvm-svn: 367413
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
The new DriverKit user-land kernel drivers in macOS 10.15 / Catalina
do not have a main() function or an LC_MAIN load command. lldb uses
the address of main() as the return address for inferior function
calls; it puts a breakpoint on main, runs the inferior function call,
and when the main() breakpoint is hit, lldb knows unambiguously that
the inferior function call ran to completion - no other function calls
main.
This change hoists the logic for finding the "entry address" from
ThreadPlanCallFunction to Target. It changes the logic to first
try to get the entry address from the main executable module,
but if that module does not have one, it will iterate through all
modules looking for an entry address.
The patch also adds code to ObjectFileMachO to use dyld's
_dyld_start function as an entry address.
<rdar://problem/52343958>
Differential Revision: https://reviews.llvm.org/D64897
llvm-svn: 366493
Summary: This patch modernizes the GetSDKVersion API and hopefully prevents problems such as the ones discovered in D61218.
Reviewers: aprantl, jasonmolenda, clayborg
Reviewed By: aprantl, clayborg
Subscribers: clayborg, labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61233
llvm-svn: 365090
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
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
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
Summary:
This file implements some general purpose data structures, and so it
belongs to the Utility module.
Reviewers: zturner, jingham, JDevlieghere, clayborg, espindola
Subscribers: emaste, mgorny, javed.absar, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D58970
llvm-svn: 355509
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
Apparently there are multiple places where MSVC complains about
instantiations with extended aligment. I think it's better to define
`_ENABLE_EXTENDED_ALIGNED_STORAGE` as suggested by the error message.
I don't have access to a Windows machine so this is all speculative.
llvm-svn: 353778
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
instead of returning the UUID through by-ref argument and a boolean
value indicating success, we can just return it directly. Since the UUID
class already has an invalid state, it can be used to denote the failure
without the additional bool.
llvm-svn: 353714
LLDB testsuite fails when built by GCC8 on:
LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp
This is because this code in LLDB codebase has undefined behavior:
#include <algorithm>
#include <string.h>
// lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:1731
static struct section_64 {
char sectname[16];
char segname[16];
} sect64 = { {'_','_','a','p','p','l','e','_','n','a','m','e','s','p','a','c'}, "__DWARF" };
int main() {
return std::min<size_t>(strlen(sect64.sectname), sizeof(sect64.sectname));
}
It has been discussed as a (false) bugreport to GCC:
wrong-code: LLDB testcase fails: SymbolFile/DWARF/find-basic-namespace.cpp
https://bugzilla.redhat.com/show_bug.cgi?id=1672436
Differential Revision: https://reviews.llvm.org/D57781
llvm-svn: 353280
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
Jonas Devlieghere