[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.

[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.com:

1094796 1095721 1095728 1095737 1095741
1095756 1095779 1095789 1095805 1214552
1229457 1232475 1274006 1274010 1293427
1364800 1364802 1364804 1364812 1364816
1374902 1374909 1384975 1399312 1420451
1431704 1454230 1454554 1454615 1454579
1454594 1454832 1457759 1458696 1461909
1467658 1487814 1487830 1487845

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

show more ...

[lldb] Set COFF module ABI from default triple and make it an option

PE/COFF can use either MSVC or GNU (MinGW) ABI for C++ code, however
LLDB had defaulted to MSVC implicitly with no way to overrid

[lldb] Set COFF module ABI from default triple and make it an option

PE/COFF can use either MSVC or GNU (MinGW) ABI for C++ code, however
LLDB had defaulted to MSVC implicitly with no way to override it. This
causes issues when debugging modules built with the GNU ABI, sometimes
even crashes.

This changes the PE/COFF plugin to set the module triple according to
the default target triple used to build LLDB. If the default target
triple is Windows and a valid environment is specified, then this
environment will be used for the module spec. This not only works for
MSVC and GNU, but also other environments.

A new setting, `plugin.object-file.pe-coff.abi`, has been added to
allow overriding this default ABI.

* Fixes https://github.com/llvm/llvm-project/issues/50775
* Fixes https://github.com/mstorsjo/llvm-mingw/issues/226
* Fixes https://github.com/mstorsjo/llvm-mingw/issues/282

Reviewed By: omjavaid

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

show more ...

[lldb] Add gnu-debuglink support for Windows PE/COFF

The specification of gnu-debuglink can be found at:
https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html

The file CRC or the CRC

[lldb] Add gnu-debuglink support for Windows PE/COFF

The specification of gnu-debuglink can be found at:
https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html

The file CRC or the CRC value from the .gnu_debuglink section is now
used to calculate the module UUID as a fallback, to allow verifying that
the debug object does match the executable. Note that if a CodeView
build id exists, it still takes precedence. This works even for MinGW
builds because LLD writes a synthetic CodeView build id which does not
get stripped from the debug object.

The `Minidump/Windows/find-module` test also needs a fix by adding a
CodeView record to the exe to match the one in the minidump, otherwise
it fails due to the new UUID calculated from the file CRC.

Fixes https://github.com/llvm/llvm-project/issues/54344

Reviewed By: DavidSpickett

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

show more ...

[lldb] Change CreateMemoryInstance to take a WritableDataBuffer

Change the CreateMemoryInstance interface to take a WritableDataBuffer.

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

[lldb] Prevent object file plugins from changing the data buffer

The current design allows that the object file contents could be mapped
by one object file plugin and then used by another. Presumabl

[lldb] Prevent object file plugins from changing the data buffer

The current design allows that the object file contents could be mapped
by one object file plugin and then used by another. Presumably the idea
here was to avoid mapping the same file twice.

This becomes an issue when one object file plugin wants to map the file
differently from the others. For example, ObjectFileELF needs to map its
memory as writable while others likeObjectFileMachO needs it to be
mapped read-only.

This patch prevents plugins from changing the buffer by passing them is
by value rather than by reference.

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

show more ...

[NFC] Refactor symbol table parsing.

Symbol table parsing has evolved over the years and many plug-ins contained duplicate code in the ObjectFile::GetSymtab() that used to be pure virtual. With this

[NFC] Refactor symbol table parsing.

Symbol table parsing has evolved over the years and many plug-ins contained duplicate code in the ObjectFile::GetSymtab() that used to be pure virtual. With this change, the "Symbtab *ObjectFile::GetSymtab()" is no longer virtual and will end up calling a new "void ObjectFile::ParseSymtab(Symtab &symtab)" pure virtual function to actually do the parsing. This helps centralize the code for parsing the symbol table and allows the ObjectFile base class to do all of the common work, like taking the necessary locks and creating the symbol table object itself. Plug-ins now just need to parse when they are asked to parse as the ParseSymtab function will only get called once.

This is a retry of the original patch https://reviews.llvm.org/D113965 which was reverted. There was a deadlock in the Manual DWARF indexing code during symbol preloading where the module was asked on the main thread to preload its symbols, and this would in turn cause the DWARF manual indexing to use a thread pool to index all of the compile units, and if there were relocations on the debug information sections, these threads could ask the ObjectFile to load section contents, which could cause a call to ObjectFileELF::RelocateSection() which would ask for the symbol table from the module and it would deadlock. We can't lock the module in ObjectFile::GetSymtab(), so the solution I am using is to use a llvm::once_flag to create the symbol table object once and then lock the Symtab object. Since all APIs on the symbol table use this lock, this will prevent anyone from using the symbol table before it is parsed and finalized and will avoid the deadlock I mentioned. ObjectFileELF::GetSymtab() was never locking the module lock before and would put off creating the symbol table until somewhere inside ObjectFileELF::GetSymtab(). Now we create it one time inside of the ObjectFile::GetSymtab() and immediately lock it which should be safe enough. This avoids the deadlocks and still provides safety.

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

show more ...

Revert "[NFC] Refactor symbol table parsing."

This reverts commit 951b107eedab1829f18049443f03339dbb0db165.

Buildbots were failing, there is a deadlock in /Users/gclayton/Documents/src/llvm/clean/l

Revert "[NFC] Refactor symbol table parsing."

This reverts commit 951b107eedab1829f18049443f03339dbb0db165.

Buildbots were failing, there is a deadlock in /Users/gclayton/Documents/src/llvm/clean/llvm-project/lldb/test/Shell/SymbolFile/DWARF/DW_AT_range-DW_FORM_sec_offset.s when ELF files try to relocate things.

show more ...

[NFC] Refactor symbol table parsing.

Symbol table parsing has evolved over the years and many plug-ins contained duplicate code in the ObjectFile::GetSymtab() that used to be pure virtual. With this

[NFC] Refactor symbol table parsing.

Symbol table parsing has evolved over the years and many plug-ins contained duplicate code in the ObjectFile::GetSymtab() that used to be pure virtual. With this change, the "Symbtab *ObjectFile::GetSymtab()" is no longer virtual and will end up calling a new "void ObjectFile::ParseSymtab(Symtab &symtab)" pure virtual function to actually do the parsing. This helps centralize the code for parsing the symbol table and allows the ObjectFile base class to do all of the common work, like taking the necessary locks and creating the symbol table object itself. Plug-ins now just need to parse when they are asked to parse as the ParseSymtab function will only get called once.

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

show more ...

[lldb] Remove ConstString from GetPluginNameStatic of some plugins

This patch deals with ObjectFile, ObjectContainer and OperatingSystem
plugins. I'll convert the other types in separate patches.

I

[lldb] Remove ConstString from GetPluginNameStatic of some plugins

This patch deals with ObjectFile, ObjectContainer and OperatingSystem
plugins. I'll convert the other types in separate patches.

In order to enable piecemeal conversion, I am leaving some ConstStrings
in the lowest PluginManager layers. I'll convert those as the last step.

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

show more ...

[lldb] Return StringRef from PluginInterface::GetPluginName

There is no reason why this function should be returning a ConstString.

While modifying these files, I also fixed several instances where

[lldb] Return StringRef from PluginInterface::GetPluginName

There is no reason why this function should be returning a ConstString.

While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.

I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.

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

show more ...

[lldb] Remove PluginInterface::GetPluginVersion

In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.

Differential Revision: https://

[lldb] Remove PluginInterface::GetPluginVersion

In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.

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

show more ...

Add a corefile style option to process save-core; skinny corefiles

Add a new feature to process save-core on Darwin systems -- for
lldb to create a user process corefile with only the dirty (modifie

Add a corefile style option to process save-core; skinny corefiles

Add a new feature to process save-core on Darwin systems -- for
lldb to create a user process corefile with only the dirty (modified
memory) pages included. All of the binaries that were used in the
corefile are assumed to still exist on the system for the duration
of the use of the corefile. A new --style option to process save-core
is added, so a full corefile can be requested if portability across
systems, or across time, is needed for this corefile.

debugserver can now identify the dirty pages in a memory region
when queried with qMemoryRegionInfo, and the size of vm pages is
given in qHostInfo.

Create a new "all image infos" LC_NOTE for Mach-O which allows us
to describe all of the binaries that were loaded in the process --
load address, UUID, file path, segment load addresses, and optionally
whether code from the binary was executing on any thread. The old
"read dyld_all_image_infos and then the in-memory Mach-O load
commands to get segment load addresses" no longer works when we
only have dirty memory.

rdar://69670807
Differential Revision: https://reviews.llvm.org/D88387

show more ...

[lldb/pecoff] Use a different llvm createBinary overload for parsing

Change the code the use the version which accepts a memory buffer,
instead of the one taking a file name.

This ensures we are no

[lldb/pecoff] Use a different llvm createBinary overload for parsing

Change the code the use the version which accepts a memory buffer,
instead of the one taking a file name.

This ensures we are not loading the file into memory twice
(ObjectFilePECOFF also loads a copy), reducing our memory footprint, as
well as enabling additional goodies in the future, like being able to
open files which don't exist on disk (D83512).

show more ...

[lldb] Remove redundant access specifiers (NFC)

[lldb] Update header guards to be consistent and compliant with LLVM (NFC)

LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pa

[lldb] Update header guards to be consistent and compliant with LLVM (NFC)

LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.

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

show more ...

[LLDB] [PECOFF] Factorize mapping section names to types using StringSwitch. NFCI.

Keep the existing special cases based on combinations of section name,
flags and sizes/offsets.

Differential Revis

[LLDB] [PECOFF] Factorize mapping section names to types using StringSwitch. NFCI.

Keep the existing special cases based on combinations of section name,
flags and sizes/offsets.

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

show more ...

[Windows] Use information from the PE32 exceptions directory to construct unwind plans

This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 6

[Windows] Use information from the PE32 exceptions directory to construct unwind plans

This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).

To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.

To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:

- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.

So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.

Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola

Reviewed By: jasonmolenda

Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits

Tags: #lldb

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

llvm-svn: 374528

show more ...

Add llvm-style RTTI to ObjectFile hierarchy

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
existi

Add llvm-style RTTI to ObjectFile hierarchy

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

show more ...

PECOFF: Fix a "memset clearing an object of non-trivial type" warning

This time, the warning pointed to an actual problem, because the
coff_opt_header structure contained a std::vector. I guess this

PECOFF: Fix a "memset clearing an object of non-trivial type" warning

This time, the warning pointed to an actual problem, because the
coff_opt_header structure contained a std::vector. I guess this happened
to work because the all-zero state was a valid representation of an
empty vector, but its not a good idea to rely on that.

I remove the memset, and have the structure clear its members in the
constructor instead.

llvm-svn: 367299

show more ...

typedef enum -> enum

Reviewed By: labath

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

llvm-svn: 360654

C.128 override, virtual keyword handling

Summary:
According to [C128] "Virtual functions should specify exactly one
of `virtual`, `override`, or `final`", I've added override where a
virtual functio

C.128 override, virtual keyword handling

Summary:
According to [C128] "Virtual functions should specify exactly one
of `virtual`, `override`, or `final`", I've added override where a
virtual function is overriden but the explicit `override` keyword
was missing. Whenever both `virtual` and `override` were specified,
I removed `virtual`. As C.128 puts it:

> [...] writing more than one of these three is both redundant and
> a potential source of errors.

I anticipate a discussion about whether or not to add `override` to
destructors but I went for it because of an example in [ISOCPP1000].
Let me repeat the comment for you here:

Consider this code:

```
struct Base {
virtual ~Base(){}
};

struct SubClass : Base {
~SubClass() {
std::cout << "It works!\n";
}
};

int main() {
std::unique_ptr<Base> ptr = std::make_unique<SubClass>();
}
```

If for some odd reason somebody removes the `virtual` keyword from the
`Base` struct, the code will no longer print `It works!`. So adding
`override` to destructors actively protects us from accidentally
breaking our code at runtime.

[C128]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c128-virtual-functions-should-specify-exactly-one-of-virtual-override-or-final
[ISOCPP1000]: https://github.com/isocpp/CppCoreGuidelines/issues/1000#issuecomment-476951555

Reviewers: teemperor, JDevlieghere, davide, shafik

Reviewed By: teemperor

Subscribers: kwk, arphaman, kadircet, lldb-commits

Tags: #lldb

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

llvm-svn: 359868

show more ...

[PECOFF] Implementation of ObjectFilePECOFF:: GetUUID()

Summary:
Provide an implementation of GetUUID() for remote debugging scenarios.

Return a PDB's GUID (or PDB70's Signature) as the UUID.

Revi

[PECOFF] Implementation of ObjectFilePECOFF:: GetUUID()

Summary:
Provide an implementation of GetUUID() for remote debugging scenarios.

Return a PDB's GUID (or PDB70's Signature) as the UUID.

Reviewers: amccarth, labath

Reviewed By: labath

Subscribers: amccarth, clayborg, Hui, labath, lldb-commits

Tags: #lldb

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

llvm-svn: 359528

show more ...

[NFC] Remove ASCII lines from comments

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

[NFC] Remove ASCII lines from comments

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

show more ...

PECOFF: Implement GetBaseAddress

COFF files are modelled in lldb as having one big container section
spanning the entire module image, with the actual sections being
subsections of that. In this mod

PECOFF: Implement GetBaseAddress

COFF files are modelled in lldb as having one big container section
spanning the entire module image, with the actual sections being
subsections of that. In this model, the base address is simply the
address of the first byte of that section.

This also removes the hack where ObjectFilePECOFF was using the
m_file_offset field to communicate this information. Using file offset
for this purpose is completely wrong, as that is supposed to indicate
where is this ObjectFile located in the file on disk. This field is only
meaningful for fat binaries, and should normally be 0.

Both PDB plugins have been updated to use GetBaseAddress instead of
GetFileOffset.

llvm-svn: 354258

show more ...

Simplify ObjectFile::GetUUID

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

Simplify ObjectFile::GetUUID

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

show more ...