[lldb] Plumb process host architecture through platform selection

To allow us to select a different platform based on where the process is
running, plumb the process host architecture through platfo

[lldb] Plumb process host architecture through platform selection

To allow us to select a different platform based on where the process is
running, plumb the process host architecture through platform selection.

This patch is in preparation for D121444 which needs this functionality
to tell apart iOS binaries running on Apple Silicon vs on a remote iOS
device.

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

show more ...

[lldb] [Platform] Support synthesizing siginfo_t

Support synthesizing the siginfo_t type from the Platform plugin.
This type is going to be used by LLDB client to process the raw siginfo
data receiv

[lldb] [Platform] Support synthesizing siginfo_t

Support synthesizing the siginfo_t type from the Platform plugin.
This type is going to be used by LLDB client to process the raw siginfo
data received from lldb-server without the necessity of relying
on target's debug info being present.

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

show more ...

[lldb] Simplify specifying of platform supported architectures

The GetSupportedArchitectureAtIndex pattern forces the use of
complicated patterns in both the implementations of the function and in
t

[lldb] Simplify specifying of platform supported architectures

The GetSupportedArchitectureAtIndex pattern forces the use of
complicated patterns in both the implementations of the function and in
the various callers.

This patch creates a new method (GetSupportedArchitectures), which
returns a list (vector) of architectures. The
GetSupportedArchitectureAtIndex is kept in order to enable incremental
rollout. Base Platform class contains implementations of both of these
methods, using the other method as the source of truth. Platforms
without infinite stacks should implement at least one of them.

This patch also ports Linux, FreeBSD and NetBSD platforms to the new
API. A new helper function (CreateArchList) is added to simplify the
common task of creating a list of ArchSpecs with the same OS but
different architectures.

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

show more ...

[lldb][AArch64] Add UnwindPlan for Linux sigreturn

This adds a specific unwind plan for AArch64 Linux sigreturn frames.
Previously we assumed that the fp would be valid here but it is not.

https://

[lldb][AArch64] Add UnwindPlan for Linux sigreturn

This adds a specific unwind plan for AArch64 Linux sigreturn frames.
Previously we assumed that the fp would be valid here but it is not.

https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/vdso/sigreturn.S

On Ubuntu Bionic it happened to point to an old frame info which meant
you got what looked like a correct backtrace. On Focal, the info is
completely invalid. (probably due to some code shuffling in libc)

This adds an UnwindPlan that knows that the sp in a sigreturn frame
points to an rt_sigframe from which we can offset to get saved
sp and pc values to backtrace correctly.

Based on LibUnwind's change: https://reviews.llvm.org/D90898

A new test is added that sets all compares the frames from the initial
signal catch to the handler break. Ensuring that the stack/frame pointer,
function name and register values match.
(this test is AArch64 Linux specific because it's the only one
with a specific unwind plan for this situation)

Fixes https://bugs.llvm.org/show_bug.cgi?id=52165

Reviewed By: omjavaid, labath

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

show more ...

[lldb] Remove ConstString from Platform plugin names

[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 ...

[lldb][NFC] Make GetResumeCountForLaunchInfo return an unsigned.

The number of resumes should always be positive to let's make this an
unsigned everywhere. Also remove the unused 'localhost' paramet

[lldb][NFC] Make GetResumeCountForLaunchInfo return an unsigned.

The number of resumes should always be positive to let's make this an
unsigned everywhere. Also remove the unused 'localhost' parameter from
ConvertArgumentsForLaunchingInShell.

show more ...

[lldb] Delete copy operations on PluginInterface class

This is a polymorphic class, copying it is a bad idea.

This was not a problem because most classes inheriting from it were
deleting their copy

[lldb] Delete copy operations on PluginInterface class

This is a polymorphic class, copying it is a bad idea.

This was not a problem because most classes inheriting from it were
deleting their copy operations themselves. However, this enables us to
delete those explicit deletions, and ensure noone forgets to add them in
the future.

show more ...

[lldb] [Platform] Move common ::DebugProcess() to PlatformPOSIX

Move common ::DebugProcess() implementation shared by Linux and NetBSD
(and to be shared by FreeBSD shortly) into PlatformPOSIX, and m

[lldb] [Platform] Move common ::DebugProcess() to PlatformPOSIX

Move common ::DebugProcess() implementation shared by Linux and NetBSD
(and to be shared by FreeBSD shortly) into PlatformPOSIX, and move
the old base implementation used only by Darwin to PlatformDarwin.

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

show more ...

[lldb] NFC remove DISALLOW_COPY_AND_ASSIGN

Summary:
This is how I applied my clang-tidy check (see
https://reviews.llvm.org/D80531) in order to remove
`DISALLOW_COPY_AND_ASSIGN` and have deleted cop

[lldb] NFC remove DISALLOW_COPY_AND_ASSIGN

Summary:
This is how I applied my clang-tidy check (see
https://reviews.llvm.org/D80531) in order to remove
`DISALLOW_COPY_AND_ASSIGN` and have deleted copy ctors and deleted
assignment operators instead.

```
lang=bash
grep DISALLOW_COPY_AND_ASSIGN /opt/notnfs/kkleine/llvm/lldb -r -l | sort | uniq > files

for i in $(cat files);
do
clang-tidy \
--checks="-*,modernize-replace-disallow-copy-and-assign-macro" \
--format-style=LLVM \
--header-filter=.* \
--fix \
-fix-errors \
$i;
done
```

Reviewers: espindola, labath, aprantl, teemperor

Reviewed By: labath, aprantl, teemperor

Subscribers: teemperor, aprantl, labath, emaste, sbc100, aheejin, MaskRay, arphaman, usaxena95, lldb-commits

Tags: #lldb

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

show more ...

[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] Decouple importing the std C++ module from the way the program is compiled

Summary:
At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the

[lldb] Decouple importing the std C++ module from the way the program is compiled

Summary:
At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program
and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to
cause a few problems or inconveniences:

* It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible
for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default
(and we can't just close all the associated bug reports).
* Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux).
* We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS).

This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit.
If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module
configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information
than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the
`Darwin` module are their own external type module with their own files).

The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths
based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some
test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism),
but for now it works and makes the feature usable.

Reviewers: aprantl, shafik, jdoerfert

Reviewed By: aprantl

Subscribers: mgorny, abidh, JDevlieghere, lldb-commits

Tags: #c_modules_in_lldb, #lldb

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

llvm-svn: 372716

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 ...

Add ability to import std module into expression parser to improve C++ debugging

Summary:
This patch is the MVP version of importing the std module into the expression parser to improve C++ debuggin

Add ability to import std module into expression parser to improve C++ debugging

Summary:
This patch is the MVP version of importing the std module into the expression parser to improve C++ debugging.

What happens in this patch is that we inject a `@import std` into our expression source code. We also
modify our internal Clang instance for parsing this expression to work with modules and debug info
at the same time (which is the main change in terms of LOC). We implicitly build the `std` module on the first use. The
C++ include paths for building are extracted from the debug info, which means that this currently only
works if the program is compiled with `-glldb -fmodules` and uses the std module. The C include paths
are currently specified by LLDB.

I enabled the tests currently only for libc++ and Linux because I could test this locally. I'll enable the tests
for other platforms once this has landed and doesn't break any bots (and I implemented the platform-specific
C include paths for them).

With this patch we can now:
* Build a libc++ as a module and import it into the expression parser.
* Read from the module while also referencing declarations from the debug info. E.g. `std::abs(local_variable)`.

What doesn't work (yet):
* Merging debug info and C++ module declarations. E.g. `std::vector<CustomClass>` doesn't work.
* Pretty much anything that involves the ASTImporter and templated code. As the ASTImporter is used for saving the result declaration, this means that we can't
call yet any function that returns a non-trivial type.
* Use libstdc++ for this, as it requires multiple include paths and Clang only emits one include path per module. Also libstdc++ doesn't support Clang modules without patches.

Reviewers: aprantl, jingham, shafik, friss, davide, serge-sans-paille

Reviewed By: aprantl

Subscribers: labath, mgorny, abidh, jdoerfert, lldb-commits

Tags: #c_modules_in_lldb, #lldb

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

llvm-svn: 355939

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
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

show more ...

Make i386-*-freebsd expression work on JIT path

* Enable i386 ABI creation for freebsd
* Added an extra argument in ABISysV_i386::PrepareTrivialCall for mmap
syscall
* Unlike linux, the last argum

Make i386-*-freebsd expression work on JIT path

* Enable i386 ABI creation for freebsd
* Added an extra argument in ABISysV_i386::PrepareTrivialCall for mmap
syscall
* Unlike linux, the last argument of mmap is actually 64-bit(off_t).
This requires us to push an additional word for the higher order bits.
* Prior to this change, ktrace dump will show mmap failures due to
invalid argument coming from the 6th mmap argument.

Patch by Karnajit Wangkhem

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

llvm-svn: 311002

show more ...

Rename Error -> Status.

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 h

Rename Error -> Status.

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

show more ...

Clean up PlatformLinux code

don't create a platform.linux setting category, as it contains no
actual settings, and I don't forsee adding any soon. Also remove some
unused includes while I'm in there

Clean up PlatformLinux code

don't create a platform.linux setting category, as it contains no
actual settings, and I don't forsee adding any soon. Also remove some
unused includes while I'm in there.

llvm-svn: 294114

show more ...

Push down more common code into PlatformPOSIX

Summary:
- GetFileWithUUID: All platforms except PlatformDarwin had this.
However, I see no reason why this code would not apply there as well.

- GetPr

Push down more common code into PlatformPOSIX

Summary:
- GetFileWithUUID: All platforms except PlatformDarwin had this.
However, I see no reason why this code would not apply there as well.

- GetProcessInfo, FindProcesses: The implementation was the same in all classes.

- GetFullNameForDylib: This code should apply to all non-darwin
platforms. I've kept the PlatformDarwin override as the situation is
different there.

Reviewers: clayborg, krytarowski, emaste

Subscribers: lldb-commits

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

llvm-svn: 294019

show more ...

Unify PlatformPOSIX::ResolveExecutable

Summary:
various platforms very using nearly identical code for this method. As far as I
can tell there was nothing platform-specific about the differences, bu

Unify PlatformPOSIX::ResolveExecutable

Summary:
various platforms very using nearly identical code for this method. As far as I
can tell there was nothing platform-specific about the differences, but rather
it looked like it was caused by tiny tweaks being made to individual copies
without affecting the overall functionality. I have taken the superset of all
these tweaks and put it into one method in the base class (incidentaly, nobody
was using the base class implementation of the method, as all classes were
overriding it). From the darwin class I took the slightly improved error
reporting (checking whether the file is readable) and the
ResolveExecutableInBundle call (which has no effect elsewhere as the function
is already a no-op on non-darwin platforms). From the linux class I took the
set-the-triple-vendor-to-host-if-unspecified tweak (present in PlatformKalimba
as well).

PlatformWindows has an identical copy as well. We could resolve that by pushing
this code further down into Platform class, that that would require pushing the
m_remote_platform_sp member as well, which seems like a bad design choice.

Reviewers: clayborg, emaste, krytarowski

Subscribers: lldb-commits

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

llvm-svn: 293910

show more ...

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging t

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.

llvm-svn: 280751

show more ...

Refactor GetSoftwareBreakpointTrapOpcode

This patch aims to reduce the code duplication among all of the platforms in GetSoftwareBreakpointTrapOpcode by pushing all common code into the Platform bas

Refactor GetSoftwareBreakpointTrapOpcode

This patch aims to reduce the code duplication among all of the platforms in GetSoftwareBreakpointTrapOpcode by pushing all common code into the Platform base class.

Differential Revision: http://reviews.llvm.org/D17395

llvm-svn: 261536

show more ...

Fix Clang-tidy modernize-use-override warnings in source/Plugins/LanguageRuntime and Platform; other minor fixes.

llvm-svn: 251374

Add functionality to the platforms to figure out the proper name for a dynamic library on the system given a basename
This will do things like,
given mylibrary,
return

libmylibrary.dylib on OSX
myli

Add functionality to the platforms to figure out the proper name for a dynamic library on the system given a basename
This will do things like,
given mylibrary,
return

libmylibrary.dylib on OSX
mylibrary.dll on Windows

and so on for other platforms
It is currently implemented for Windows, Darwin, and Linux. Other platforms should fill in accordingly

llvm-svn: 246131

show more ...