[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
inf

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.

After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.

show more ...

[lldb] Convert "LLDB" log channel to the new API

Remove ConstString from DynamicLoader, JITLoader and Instruction 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] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,mo

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,

https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html

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

show more ...

Target::ReadMemory read from read-only binary file Section, not memory

Commiting this patch for Augusto Noronha who is getting set
up still.

This patch changes Target::ReadMemory so the default beh

Target::ReadMemory read from read-only binary file Section, not memory

Commiting this patch for Augusto Noronha who is getting set
up still.

This patch changes Target::ReadMemory so the default behavior
when a read is in a Section that is read-only is to fetch the
data from the local binary image, instead of reading it from
memory. Update all callers to use their old preferences
(the old prefer_file_cache bool) using the new API; we should
revisit these calls and see if they really intend to read
live memory, or if reading from a read-only Section would be
equivalent and important for performance-sensitive cases.

rdar://30634422

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

show more ...

[lldb] s/ExecutionContext/Target in Disassembler

Some functions in this file only use the "target" component of an
execution context. Adjust the argument lists to reflect that.

This avoids some def

[lldb] s/ExecutionContext/Target in Disassembler

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.

show more ...

[lldb/Plugin] s/LLDB_PLUGIN/LLDB_PLUGIN_DEFINE/ (NFC)

Rename LLDB_PLUGIN to LLDB_PLUGIN_DEFINE as Pavel suggested in D73067 to
avoid name conflict.

[LLDB] Fix GCC warnings about extra semicolons. NFC.

[lldb/Plugins] Use external functions to (de)initialize plugins

This is a step towards making the initialize and terminate calls be
generated by CMake, which in turn is towards making it possible to

[lldb/Plugins] Use external functions to (de)initialize plugins

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

show more ...

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

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

show more ...

Correctly use GetLoadedModuleList to take advantage of libraries-svr4

Summary:
Here's a replacement for D62504. I thought I could use LoadModules to implement this but in reality I can't because the

Correctly use GetLoadedModuleList to take advantage of libraries-svr4

Summary:
Here's a replacement for D62504. I thought I could use LoadModules to implement this but in reality I can't because there are at few issues with it:
* The LoadModules assumes that the list returned by GetLoadedModuleList is comprehensive in the sense that reflects all the mapped segments, however, this is not true, for instance VDSO entry is not there since it's loaded manually by LoadVDSO using GetMemoryRegionInfo and it doesn't represent a specific shared object in disk. Because of this LoadModules will unload the VDSO module.
* The loader (interpreter) module might have also been loaded using GetMemoryRegionInfo, this is true when we launch the process and the rendezvous structure is not yet available (done through LoadInterpreterModule()). The problem here is that this entry will point to the same file name as the one found in /proc/pid/maps, however, when we read the same module from the r_debug.link_map structure it might be under a different name. This is true at least on CentOS where the loader is a symlink. Because of this LoadModules will unload and load the module in a way where the rendezvous breakpoint is unresolved but not resolved again (because we add the new module first and remove the old one after).

The symlink issue might be fixable by first unloading the old and loading the news (but sounds super brittle), however, I'm not sure how to fix the VDSO issue.
Since I can't trust it I'm just going to use GetLoadedModuleList directly with the same logic that we use today for when we read the linked list in lldb. The only safe thing to do here is to only calculate differences between different snapshots of the svr4 packet itself. This will also cut the dependency this plugin has from LoadModules.

I separated the 2 logics into 2 different functions (remote and not remote) because I don't like mixing 2 different logics in the same function with if/else's. Two different functions makes it easier to reason with I believe. However, I did abstract away the logic that decides if we should take a snapshot or add/remove modules so both functions could reuse it.

The other difference between the two is that on the UpdateSOEntriesFromRemote I take the snapshot only once when state = Consistent because I didn't find a good reason to always update that, as we already got the list from state = Add | Remove. I probably should use the same logic on UpdateSOEntries though I don't see a reason not to since it's really using the same data, just read in different places. Any thoughts here?

It might also be worthwhile to add a test to make sure we don't unload modules that were not actually "unloaded" like the vdso. I haven't done this yet though.
This diff is also missing the option for svr4 like proposed in https://reviews.llvm.org/D62503#1564296, I'll start working on this but wanted to have this up first.

Reviewers: labath, jankratochvil, clayborg, xiaobai

Reviewed By: labath

Subscribers: srhines, JDevlieghere, lldb-commits

Tags: #lldb

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

llvm-svn: 367020

show more ...

[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)

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 for

[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)

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

show more ...

Rename Target::GetSharedModule to Target::GetOrCreateModule.

Add a flag to control whether the ModulesDidLoad notification is
called when a module is added. If the notifications are disabled,
the c

Rename Target::GetSharedModule to Target::GetOrCreateModule.

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

show more ...

[win] Resolve the module only if there isn't one already

Summary:
This commit modifies the OnLoadModule method to resolve the module
unless we already have one

Change by Hui Huang to fix the failin

[win] Resolve the module only if there isn't one already

Summary:
This commit modifies the OnLoadModule method to resolve the module
unless we already have one

Change by Hui Huang to fix the failing LLDB tests on Windows

Reviewers: labath, asmith

Subscribers: abidh, lldb-commits

Tags: #lldb

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

llvm-svn: 354172

show more ...

Implement GetLoadAddress for the Windows process plugin

Summary:
When a process is loaded, update its sections with the load address to resolve any created breakpoints. For the remote debugging case

Implement GetLoadAddress for the Windows process plugin

Summary:
When a process is loaded, update its sections with the load address to resolve any created breakpoints. For the remote debugging case, the debugged process is launched remotely so GetLoadAddress is intended to pass the load address from remote to LLDB (client).


Reviewers: zturner, llvm-commits, clayborg, labath

Reviewed By: labath

Subscribers: mgorny, sas, Hui, clayborg, labath, lldb-commits

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

llvm-svn: 354099

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

Implement WindowsDYLD::DidAttach for use with gdb-server attach

Summary:
Windows lldb debugging currently uses a process plugin to handle
launching and attaching to a process. Launching a process vi

Implement WindowsDYLD::DidAttach for use with gdb-server attach

Summary:
Windows lldb debugging currently uses a process plugin to handle
launching and attaching to a process. Launching a process via a debug
server (e.g. ds2) and attaching to it with `gdb-remote port` currently
doesn't communicate address information of the executable properly.

Implement DynamicLoaderWindowsDYLD::DidAttach which allow us to
obtain the proper executable load address.

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

llvm-svn: 348526

show more ...

Revert "Implement basic DidAttach and DidLaunch for DynamicLoaderWindowsDYLD"

This breaks many tests on Windows, which now all fail with an error such
as "Unable to read memory at address <xxxxxxxx>

Revert "Implement basic DidAttach and DidLaunch for DynamicLoaderWindowsDYLD"

This breaks many tests on Windows, which now all fail with an error such
as "Unable to read memory at address <xxxxxxxx>".

llvm-svn: 347174

show more ...

Implement basic DidAttach and DidLaunch for DynamicLoaderWindowsDYLD

Summary:
This commit implements basic DidAttach and DidLaunch for the windows
DynamicLoader plugin which allow us to load shared

Implement basic DidAttach and DidLaunch for DynamicLoaderWindowsDYLD

Summary:
This commit implements basic DidAttach and DidLaunch for the windows
DynamicLoader plugin which allow us to load shared libraries from the
inferior.

Reviewers: sas, zturner

Reviewed By: zturner

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

llvm-svn: 346994

show more ...

Implement trampoline step-through for Windows-x86.

Summary:
This is required to be able to step through calls to external functions
that are not properly marked with __declspec(dllimport). When a ca

Implement trampoline step-through for Windows-x86.

Summary:
This is required to be able to step through calls to external functions
that are not properly marked with __declspec(dllimport). When a call
like this is emitted, the linker will inject a trampoline to produce an
indirect call through the IAT.

Reviewers: zturner, jingham

Reviewed By: jingham

Subscribers: sas, jingham, lldb-commits

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

llvm-svn: 314045

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

Prevent at compile time converting from Error::success() to Expected<T>

This would trigger an assertion at runtime otherwise.

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

llvm-svn: 286562

Make the Error class constructor protected

This is forcing to use Error::success(), which is in a wide majority
of cases a lot more readable.

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

Make the Error class constructor protected

This is forcing to use Error::success(), which is in a wide majority
of cases a lot more readable.

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

llvm-svn: 286561

show more ...