[NFC] Don't bother with unstripped binary w/ dSYM, don't DebugSymbols twice

This patch addresses two perf issues when we find a dSYM on macOS
after calling into the DebugSymbols framework. First, w

[NFC] Don't bother with unstripped binary w/ dSYM, don't DebugSymbols twice

This patch addresses two perf issues when we find a dSYM on macOS
after calling into the DebugSymbols framework. First, when we have
a local (probably stripped) binaary, we find the dSYM and we may
be told about the location of the symbol rich binary (probably
unstripped) which may be on a remote filesystem. We don't need the
unstripped binary, use the local binary we already have.
Second, after we've found the path to the dSYM, save that in the Module
so we don't call into DebugSymbols a second time later on to
rediscover it. If the user has a DBGShellCommands set, we need to
exec that process twice, serially, which can add up.

Differential Revision: https://reviews.llvm.org/D125616
rdar://84576917

show more ...

[lldb] Show the DBGError if dsymForUUID can't find a dSYM

Show the user the DBGError (if available) when dsymForUUID fails.

rdar://90949180

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

[lldb] Remove reproducer logic from LocateSymbolFileMacOSX

[lldb] Format LocateSymbolFileMacOSX (NFC)

[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

[lldb] Unbreak the macOS build after dfd499a61c45778b7f01458d50ccc384343f53d5

Ignore DBGArchitecture from dsymForUUID's plist

When the architecture from the returned plist differs from the
architecture lldb will pick when loading the binary file, lldb will
reject the binary a

Ignore DBGArchitecture from dsymForUUID's plist

When the architecture from the returned plist differs from the
architecture lldb will pick when loading the binary file, lldb will
reject the binary as not matching. We are working with UUID's in
this case, so an architecture is not disambiguating anything; it
just opens this possibility for failing to load the specified binary.
Stop reading the architecture from the plist.

<rdar://problem/71612561>
Differential revision: https://reviews.llvm.org/D92692

show more ...

Increase timeout to find a dSYM in macos DownloadObjectAndSymbolFile

With a large dSYM over a slow home connection, the two minute timeout
would sometimes be exceeded, and we haven't seen instances

Increase timeout to find a dSYM in macos DownloadObjectAndSymbolFile

With a large dSYM over a slow home connection, the two minute timeout
would sometimes be exceeded, and we haven't seen instances of a
long timeout causing people any problems, so we're bumping it up.

640 seconds ought to be enough for anyone.

<rdar://problem/67759526>

show more ...

[lldb] Add a SymbolFileProvider to record and replay calls to dsymForUUID

When replaying a reproducer captured from a core file, we always use
dsymForUUID for the kernel binary. When enabled, we als

[lldb] Add a SymbolFileProvider to record and replay calls to dsymForUUID

When replaying a reproducer captured from a core file, we always use
dsymForUUID for the kernel binary. When enabled, we also use it to find
kexts. Since these files are already contained in the reproducer,
there's no reason to call out to an external tool. If the tool returns a
different result, e.g. because the dSYM got garbage collected, it will
break reproducer replay. The SymbolFileProvider solves the issue by
mapping UUIDs to module and symbol paths in the reproducer.

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

show more ...

[lldb/Symbol] Reimplement Symbols::FindSymbolFileInBundle to use the VFS

This reimplements Symbols::FindSymbolFileInBundle to use the VFS-aware
recursive directory iterator. This is needed for repro

[lldb/Symbol] Reimplement Symbols::FindSymbolFileInBundle to use the VFS

This reimplements Symbols::FindSymbolFileInBundle to use the VFS-aware
recursive directory iterator. This is needed for reproducer replay.

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

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

[lldb] Fix macOS build by replacing nullptr with FileSpec()

Before we had a implicit conversion from nullptr to FileSpec
which was thankfully removed.

[Utility] Replace `lldb_private::CleanUp` by `llvm::scope_exit`

This removes the CleanUp class and replaces its usages with llvm's
ScopeExit, which has similar semantics.

Differential revision: htt

[Utility] Replace `lldb_private::CleanUp` by `llvm::scope_exit`

This removes the CleanUp class and replaces its usages with llvm's
ScopeExit, which has similar semantics.

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

llvm-svn: 371474

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

Don't link against the DebugSymbols private framework; try to dlopen
+ dlsym the two functions we need from there at runtime.

I'm not maintaining a negative cache if DebugSymbols is absent, so
we'll

Don't link against the DebugSymbols private framework; try to dlopen
+ dlsym the two functions we need from there at runtime.

I'm not maintaining a negative cache if DebugSymbols is absent, so
we'll try to dlopen() it on every call to
LocateMacOSXFilesUsingDebugSymbols but this file is only built on
mac and iOS type systems, so there's a slight perf impact running
lldb on an iOS type system.

I store the function pointer results in two global variables without
any locking; two threads calling into LocateMacOSXFilesUsingDebugSymbols
for the first time will both try to set these fptrs, but they'll be
setting them to the same value, so I'm not too worried.

I didn't see where in the cmake build configurations we link against
DebugSymbols, but I removed the dependency from the xcode project
file.

<rdar://problem/49458356>

llvm-svn: 364243

show more ...

Fix file names in file headers. NFC

llvm-svn: 360554

Increase timeout in Symbols::DownloadObjectAndSymbolFile
from 30 seconds to 120 seconds. We've seen cases where
this symbol lookup can exceed 30 seconds for people
working remotely.

<rdar://proble

Increase timeout in Symbols::DownloadObjectAndSymbolFile
from 30 seconds to 120 seconds. We've seen cases where
this symbol lookup can exceed 30 seconds for people
working remotely.

<rdar://problem/48460476>

llvm-svn: 355169

show more ...

Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cpp

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 f

Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cpp

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

show more ...