This is a no-op because it is set later on unconditionally again, but
it's far less confusing this way and consistent with how the setters
are initialized.
Originally committed as 416fa7720e
Reverted (due to buildbot failure - breaking lldb) in 7a45aeacf3.
I still can't seem to build lldb locally, but Pavel Labath has kindly
provided a potential fix to preserve the old behavior in lldb by
registering a simple recoverable error handler there that prints to the
desired stream in lldb, rather than stderr.
Make it possible to capture reproducers from the API test suite. Given
the symmetry between capture and replay, this patch also adds the
necessary code for replay. For now this is a NO-OP until the
corresponding reproducer instrumentation changes land.
For more info please refer to the RFC on lldb-dev:
http://lists.llvm.org/pipermail/lldb-dev/2020-April/016100.html
Differential revision: https://reviews.llvm.org/D77588
If a plan is not private, "thread plan discard" can discard it. It would
not be hard to write reliable scripted plan if its subplans could get
removed out from under it.
The instrumentation unit tests' current implementation uses global
variables to track constructor calls for the instrumented classes during
replay. This is suboptimal because it indirectly relies on how the
reproducer instrumentation is implemented. I found out when adding
support for passive replay and the test broke because we made an extra
(temporary) copy of the instrumented objects.
Additionally, the old approach wasn't very self-explanatory. It took me
a bit of time to understand why we were expecting the number of objects
in the test.
This patch rewrites the test and uses the index-to-object-mapping to
verify the objects created during replay. You can now specify the
expected objects, in order, and whether they should be valid or not. I
find that it makes the tests much easier to understand. More
importantly, this approach is resilient to implementation detail changes
in the instrumentation.
It removes some needless deep indentation and some redundant statements.
It prepares the code for a more clean next patch - DWARF index callbacks
D77327.
Differential Revision: https://reviews.llvm.org/D77326
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
1;95;0csets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.
This reapplies the previously reverted commit, but without support for
ClassTemplateSpecializations, which I'm going to look into separately.
rdar://problem/59634380
Differential Revision: https://reviews.llvm.org/D75488
Add a small artificial delay in replay mode before exiting to ensure
that all asynchronous events have completed. This should reduce the
level of replay flakiness on some of the slower bots.
The synchronization logic in the previous had a subtle bug. Moving of
the "m_read_thread_did_exit = true" into the critical section made it
possible for some threads calling SynchronizeWithReadThread call to get
stuck. This could happen if there were already past the point where they
checked this variable. In that case, they would block on waiting for the
eBroadcastBitNoMorePendingInput event, which would never come as the
read thread was blocked on getting the synchronization mutex.
The new version moves that line out of the critical section and before
the sending of the eBroadcastBitNoMorePendingInput event, and also adds
some comments to explain why the things need to be in this sequence:
- m_read_thread_did_exit = true: prevents new threads for waiting on
events
- eBroadcastBitNoMorePendingInput: unblock any current thread waiting
for the event
- Disconnect(): close the connection. This is the only bit that needs to
be in the critical section, and this is to ensure that we don't close
the connection while the synchronizing thread is mucking with it.
Original commit message follows:
Communication::SynchronizeWithReadThread is called whenever a process
stops to ensure that we process all of its stdout before we report the
stop. If the process exits, we first call this method, and then close
the connection.
However, when the child process exits, the thread reading its stdout
will usually (but not always) read an EOF because the other end of the
pty has been closed. In response to an EOF, the Communication read
thread closes it's end of the connection too.
This can result in a race where the read thread is closing the
connection while the synchronizing thread is attempting to get its
attention via Connection::InterruptRead.
The fix is to hold the synchronization mutex while closing the
connection.
I've found this issue while tracking down a rare flake in some of the
vscode tests. I am not sure this is the cause of those failures (as I
would have expected this issue to manifest itself differently), but it
is an issue nonetheless.
The attached test demonstrates the steps needed to reproduce the race.
It will fail under tsan without this patch.
Reviewers: clayborg, JDevlieghere
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77295
Summary:
Communication::SynchronizeWithReadThread is called whenever a process
stops to ensure that we process all of its stdout before we report the
stop. If the process exits, we first call this method, and then close
the connection.
However, when the child process exits, the thread reading its stdout
will usually (but not always) read an EOF because the other end of the
pty has been closed. In response to an EOF, the Communication read
thread closes it's end of the connection too.
This can result in a race where the read thread is closing the
connection while the synchronizing thread is attempting to get its
attention via Connection::InterruptRead.
The fix is to hold the synchronization mutex while closing the
connection.
I've found this issue while tracking down a rare flake in some of the
vscode tests. I am not sure this is the cause of those failures (as I
would have expected this issue to manifest itself differently), but it
is an issue nonetheless.
The attached test demonstrates the steps needed to reproduce the race.
It will fail under tsan without this patch.
Reviewers: clayborg, JDevlieghere
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77295
I fixed the bug that the "log timer" has no tab command.
Original code has the only CommandObjectLogTimer class, but it is not
sufficient. Thus I divided the content of CommandObjectLog class into
CommandObjectLogEnable class, CommandObjectLogDisable class,
CommandObjectLogDump class, CommandObjectLogReset class,
CommandObjectLogIncrement class.
Reviewed by: teemperor
Differential Revision: https://reviews.llvm.org/D76906
Summary:
This adds support for commands created through the API to support autorepeat.
This covers the case of single word and multiword commands.
Comprehensive tests are included as well.
Reviewers: labath, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77444
Discussed on lldb-dev with Pavel Labath. This doesn't work for
background processes [causes Python to be stuck forever], and it's
unclear whether it's needed. There's no test, also. If this turns
out to be useful, it can be recommitted with a functional implementation
and a test.
We would return `LLDB_INVALID_IMAGE_TOKEN` for the address rather than
the correct value of `LLDB_IMAGE_ADDRESS`. This would result in the
check for the return value to silently pass on x64 as the invalid
address and invalid token are of different sizes (`size_t` vs
`uintprr_t`). This corrects the return value to `LLDB_INVALID_ADDRESS`
and addresses the rest to reset the mapped address to the invalid value.
This was found by inspection when trying to implement module support for
Windows.
This is mostly useful for Swift support; it allows LLDB to substitute
a matching SDK it shipped with instead of the sysroot path that was
used at compile time.
The goal of this is to make the Xcode SDK something that behaves more
like the compiler's resource directory, as in that it ships with LLDB
rather than with the debugged program. This important primarily for
importing Swift and Clang modules in the expression evaluator, and
getting at the APINotes from the SDK in Swift.
For a cross-debugging scenario, this means you have to have an SDK for
your target installed alongside LLDB. In Xcode this will always be the
case.
rdar://problem/60640017
Differential Revision: https://reviews.llvm.org/D76471
Greg Clayton a few years ago.
My patch to augment the symbol table in Mach-O files with the
dyld trie exports data structure only categorized symbols as code
or data, but Greg Clayton had a patch to do something similar to
swift a few years ago that had a more extensive categorization of
symbols, as well as extracting some objc class/ivar names from the
entries. This patch is basically just Greg's, updated a bit and
with a test case added to it.
<rdar://problem/50791451>
Differential Revision: https://reviews.llvm.org/D77369
This patch adds parts of the stack that should be useful for unwinding
to the jThreadsInfo reply from lldb-server. We return the top of the
stack (12 words), and we also try to walk the frame pointer linked list
and return the memory containing frame pointer and return address pairs.
The idea is to cover the cases with and without frame pointer omission.
Differential Revision: https://reviews.llvm.org/D74398
Summary:
Usually when Clang emits an error Fix-It it does two things. It emits the diagnostic and then it fixes the
currently generated AST to reflect the applied Fix-It. While emitting the diagnostic is easy to implement,
fixing the currently generated AST is often tricky. That causes that some Fix-Its just keep the AST as-is or
abort the parsing process entirely. Once the parser stopped, any Fix-Its for the rest of the expression are
not detected and when the user manually applies the Fix-It, the next expression will just produce a new
Fix-It.
This is often occurring with quickly made Fix-Its that are just used to bridge temporary API changes
and that often are not worth implementing a proper API fixup in addition to the diagnostic. To still
give some kind of reasonable user-experience for users that have these Fix-Its and rely on them to
fix their expressions, this patch adds the ability to retry parsing with applied Fix-Its multiple time to
give the normal Fix-It experience where things Clang knows how to fix are not causing actual expression
error (at least when automatically applying Fix-Its is activated).
The way this is implemented is just by having another setting in the expression options that specify how
often we should try applying Fix-Its and then reparse the expression. The default setting is still 1 for everyone
so this should not affect the speed in which we fail to parse expressions.
Reviewers: jingham, JDevlieghere, friss, shafik
Reviewed By: shafik
Subscribers: shafik, abidh
Differential Revision: https://reviews.llvm.org/D77214
Summary:
LLDB currently applies Fix-Its if they are attached to a Clang diagnostic that has the
severity "error". Fix-Its connected to warnings and other severities are supposed to
be ignored as LLDB doesn't seem to trust Clang Fix-Its in these situations.
However, LLDB also ignores all Fix-Its coming from "note:" diagnostics. These diagnostics
are usually emitted alongside other diagnostics (both warnings and errors), either to keep
a single diagnostic message shorter or because the Fix-It is in a different source line. As they
are technically their own (non-error) diagnostics, we currently are ignoring all Fix-Its associated with them.
For example, this is a possible Clang diagnostic with a Fix-It that is currently ignored:
```
error: <user expression 1>:2:10: too many arguments provided to function-like macro invocation
ToStr(0, {,})
^
<user expression 1>:1:9: macro 'ToStr' defined here
#define ToStr(x) #x
^
<user expression 1>:2:1: cannot use initializer list at the beginning of a macro argument
ToStr(0, {,})
^ ~~~~
```
We also don't store "note:" diagnostics at all, as LLDB's abstraction around the whole diagnostic
concept doesn't have such a concept. The text of "note:" diagnostics is instead
appended to the last non-note diagnostic (which is causing that there is no "note:" text in the
diagnostic above, as all the "note:" diagnostics have been appended to the first "error: ..." text).
This patch fixes the ignored Fix-Its in note-diagnostics by appending them to the last non-note
diagnostic, similar to the way we handle the text in these diagnostics.
Reviewers: JDevlieghere, jingham
Reviewed By: JDevlieghere
Subscribers: abidh
Differential Revision: https://reviews.llvm.org/D77055
This is a preparation for an upcoming patch which adds support for
DWARFv5 unit index sections. The patch adds tag "_EXT_" to identifiers
which reference sections that are deprecated in the DWARFv5 standard.
See D75929 for the discussion.
Differential Revision: https://reviews.llvm.org/D77141
Summary:
A recent change in ThreadPlans introduced this little compilation error.
Seems to be related to the work around https://reviews.llvm.org/D76814.
Reviewers: clayborg, labath, jingham
Reviewed By: jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77450
Summary:
In this diff of mine D77186 I introduce a bug in the replace operation, where I was failing fast by mistake.
Besides, a similar problem existed in the insert-after operation, where it was failing fast.
Finally, the remove operation was wrong, as it was not using the indices provided by the users.
I fixed those issues and added some tests account for cases with multiple elements in these requests.
Reviewers: labath, clayborg
Reviewed By: labath
Subscribers: mgrang, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77324
Apparently the intention was to copy the condition above:
if (types.GetSize() >= max_matches)
break;
So that if the iteration stopped because of too many matches we do not
add even more matches in this 'Clang modules' block downward.
It was implemented by:
SymbolFileDWARF: Unconditionally scan through clang modules. NFCish
fe9eaadd68
Differential Revision: https://reviews.llvm.org/D77336
that were not reported by the OS plugin. To facilitate this, move
adding/updating the ThreadPlans for a Thread to the ThreadPlanStackMap.
Also move dumping thread plans there as well.
Added some tests for "thread plan list" and "thread plan discard" since
I didn't seem to have written any originally.
Differential Revision: https://reviews.llvm.org/D76814
It is an obvious part of D77326.
It removes some needless deep indentation and some redundant statements.
It prepares the code for a more clean next patch - DWARF index callbacks
in D77327.
LLDB relies on empty FileSpecs being invalid files, for example, they
don't exists. Currently this assumption does not always hold during
reproducer replay, because we pass the result of GetPath to the VFS.
This is an empty string, which the VFS converts to an absolute directory
by prepending the current working directory, before looking it up in the
YAML mapping. This means that an empty FileSpec will exist when the
current working directory does. This breaks at least one test
(TestAddDsymCommand.py) when ran from replay.
This patch special cases empty FileSpecs and returns a sensible result
before calling GetPath and forwarding the call.
Differential revision: https://reviews.llvm.org/D77351
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
The old name was a bit misleading because the functions actually return
contributions to the corresponding sections.
Differential revision: https://reviews.llvm.org/D77302
--script-language python and --script-language lua are both valid now.
Reviewed by: JDevlieghere
Differential Revision: https://reviews.llvm.org/D77241
This patch was reverted because it introduced a failure in
TestHelloWorld.py. The reason for that was running "ls" shell command
failed as it was evaluated in an environment with an empty path. This
has now been fixed with D77123, which ensures that all shell commands
inherit the host environment, so this patch should be safe to recommit.
The original commit message was:
A defensive check in ProcessLauncherWindows meant that we would never
attempt to launch a process with a completely empty environment -- the
host environment would be used instead. Instead, I make the function add
an extra null wchar_t at the end of an empty environment. The
documentation on this is a bit fuzzy, but it seems to be what is needed
to make windows accept these kinds of environments.
Reviewers: amccarth, friss
Differential Revision: https://reviews.llvm.org/D76835
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
sets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.
rdar://problem/59634380
Differential Revision: https://reviews.llvm.org/D75488
Previously, this was reverted in bf65f19b becuase it checked whether
TARGET_OS_EMBEDDED is defined, but that macro is always defined.
Update the condition to check that TARGET_OS_OSX is true.
Summary:
Several lldb-vscode users have noticed that when a source map rule is invalid (because a folder doesn't exist anymore), the rest of the source maps from their configurations are not applied.
This happens because lldb-vscode executes a single "settings set target.source-map" command with all the source maps and LLDB processes them one by one until one fails.
Instead of doing this, we can process in LLDB all the source map rules and apply the valid ones instead of failing fast.
Reviewers: clayborg, labath, kusmour, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77186
The RuntimeFunction struct, which PECallFrameInfo interprets, has a
different layout and differnet semantics on all architectures.
Differential Revision: https://reviews.llvm.org/D77000
Summary:
On most hosts we were running shell commands with an empty environment.
The only exception was windows, which was inheriting the host enviroment
mostly by accident.
Running the commands in an empty environment does not sound like a
sensible default, so this patch changes Host::RunShellCommand to inherit
the host environment. This impacts both commands run via
SBPlatform::Run (in case of host platforms), as well as the "platform
shell" CLI command.
Reviewers: jingham, friss
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77123
The FileCollector in LLDB collects every files that's used during a
debug session when capture is enabled. This ensures that the reproducer
only contains the files necessary to reproduce. This approach is not a
good fit for the dSYM bundle, which is a directory on disk, but should
be treated as a single unit.
On macOS LLDB have automatically find the matching dSYM for a binary by
its UUID. Having a incomplete dSYM in a reproducer can break debugging
even when reproducers are disabled.
This patch adds a was to specify a directory of interest to the
reproducers. It is called from SymbolVendorMacOSX with the path of the
dSYMs used by LLDB.
Differential revision: https://reviews.llvm.org/D76672
SBPlatform::GetHostPlatform was missing the reproducer instrumentation
macros. Fixed by running lldb-instr on SBPlatform.cpp:
$ ./bin/lldb-instr ../llvm-project/lldb/source/API/SBPlatform.cpp
This patch fixes a crash that happens on the DWARF expression evaluator
when trying to access the top of the stack while it's empty.
rdar://60512489
Differential Revision: https://reviews.llvm.org/D77108
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch fixes a crash that happens on the DWARF expression evaluator
when trying to access the top of the stack while it's empty.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Leverage ARM ELF build attribute section to create ELF attribute section
for RISC-V. Extract the common part of parsing logic for this section
into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h].
Differential Revision: https://reviews.llvm.org/D74023
The FileCollector in LLDB collects every files that's used during a
debug session when capture is enabled. This ensures that the reproducer
only contains the files necessary to reproduce. This approach is not a
good fit for the dSYM bundle, which is a directory on disk, but should
be treated as a single unit.
On macOS LLDB have automatically find the matching dSYM for a binary by
its UUID. Having a incomplete dSYM in a reproducer can break debugging
even when reproducers are disabled.
This patch adds a was to specify a directory of interest to the
reproducers. It is called from SymbolVendorMacOSX with the path of the
dSYMs used by LLDB.
Differential revision: https://reviews.llvm.org/D76672
This reverts commit because of test failures in TestHelloWorld.
It seems that this test (specifically running "ls" as a platform shell
command) depended on the implicit passing of the host environment.
The fix should be fairly simple (inherit the environment explicitly),
but it may take me a while to figure where exactly to do that. Revert
while I am figuring that out.
Summary:
A defensive check in ProcessLauncherWindows meant that we would never
attempt to launch a process with a completely empty environment -- the
host environment would be used instead. Instead, I make the function add
an extra null wchar_t at the end of an empty environment. The
documentation on this is a bit fuzzy, but it seems to be what is needed
to make windows accept these kinds of environments.
Reviewers: amccarth, friss
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76835
Summary:
D73024 seems to have fixed one set crash, but it introduced another.
Namely, if a class contains a covariant method returning itself, the
logic in MaybeCompleteReturnType could cause us to attempt a recursive
import, which would result in an assertion failure in
clang::DeclContext::removeDecl.
For some reason, this only manifested itself if the class contained at
least two member variables, and the class itself was imported as a
result of a recursive covariant import.
This patch fixes the crash by not attempting to import classes which are
already completed in MaybeCompleteReturnType. However, it's not clear to
me if this is the right fix, or if this should be handled automatically
by functions lower in the stack.
Reviewers: teemperor, shafik
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76840
LLDB only automatically applies Fix-Its from errors, but not from warnings.
Currently we only store Fix-Its from errors and then later apply all Fix-Its
we stored. This moves the filter to the application phase, so that we now
store *all* Fix-Its but only apply Fix-Its from errors later on.
This is NFC preparation for an upcoming patch.
Summary:
Currently top-level expressions won't automatically get Fix-Its applied. The reason
for that is that we only set the `m_fixed_text` member if we have a wrapping
source code (I.e. `m_source_code` is not zero and is wrapping some expressions).
This patch just always sets `m_fixed_text` to get this working.
Reviewers: labath, jingham
Reviewed By: labath
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D77042
In ObjectFileMachO we construct the symbol table from multiple
sources -- primarily the binary's nlist records, but when the nlist
symbols have been stripped, we would augment those with function
start address from the LC_FUNCTION_STARTS or eh_frame. This patch
adds another source of symbols - the exported symbols that the
dynamic linker, dyld, uses at runtime from its trie structure. This
provides us names and addresses for these functions/data.
This patch removes the code from ParseSymtab that would reject an
empty symbol table / nlist source. It adds a new symbols_added
set which tracks the address of every symbol we've added to the
symtab. We add symbols in most-information-ful order, and before
adding a symbol from less-informational-ful source (e.g.
LC_FUNCTION_STARTS with no function name), we check if that symbol
has already been added.
On targets with thumb code generation, instead of using the 0th bit
in these addresses in FunctionStarts (or now the trie entries), we
use the data field of FunctionStarts (formerly used to track if the
func_start should be added) and a flag for the trie entries to
encode this, and only store the actual addresses in the symbols_seen
and these vectors.
<rdar://problem/50791451>
Differential revision: https://reviews.llvm.org/D76758
CPlusPlusNameParser is used in several places on of them is during IR execution and setting breakpoints to pull information C++ like the basename, the context and arguments.
Currently it does not handle templated operator< properly, because of idiosyncrasy is how clang generates debug info for these cases.
It uses clang::Lexer which will tokenize operator<<A::B> into:
tok::kw_operator
tok::lessless
tok::raw_identifier
Later on the parser in ConsumeOperator() does not handle this case properly and we end up failing to parse.
Differential Revision: https://reviews.llvm.org/D76168
GetDeveloperDirectory returns a const char* which is NULL when we cannot
find the developer directory. This crashes in
PlatformDarwinKernel::CollectKextAndKernelDirectories because we're
unconditionally assigning it to a std::string. Coincidentally I just
refactored a bunch of code in PlatformMacOSX so instead of a ad-hoc fix
I've reimplemented the method based on GetXcodeContentsDirectory.
The change is mostly NFC. Obviously it fixes the crash, but it also
removes support for finding the Xcode directory through he legacy
$XCODE_SELECT_PREFIX_DIR/usr/share/xcode-select/xcode_dir_path.
Differential revision: https://reviews.llvm.org/D76938
When parsing DWARF and laying out bit-fields we currently don't take into account whether we have a base class or not.
Currently if the first field is a bit-field but the bit offset is due a field we inherit from a base class we currently
treat it as an unnamed bit-field and therefore add an extra field.
This fix will not check if we have a base class and assume that this offset is due to members we are inheriting from the base.
We are currently seeing asserts during codegen when debugging clang::DiagnosticOptions.
This assumption will fail in the case where the first field in the derived class in an unnamed bit-field. Fixing the first field
being an unnamed bit-field looks like it will require a larger change since we will need a way to track or discover the last field offset of the bases(s).
Differential Revision: https://reviews.llvm.org/D76808
In breakpad, only x86 (and mips) registers have a leading '$' in their
names. Arm architectures use plain register names.
Previously, lldb was assuming all registers have a '$'. Fix the code to
match the (unfortunately, inconsistent) reality.
Summary:
When using IPv6 host:port pairs, typically the host is put inside
brackets, such as [2601🔢...:0213]:5555, and the UriParser
can handle this format.
However, the Android infrastructure in LLDB assumes an additional
brackets around the host:port pair, such that the entire host:port
string can be treated as the host (which is used as an Android Serial
Number), and UriParser cannot handle multiple brackets. Parsing
inputs with such extra backets requires searching the closing bracket
from the right.
Test: BracketedHostnameWithPortIPv6 covers the case mentioned above
Reviewers: #lldb, labath
Reviewed By: labath
Subscribers: kwk, shafik, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76736
lldbassert is the macro that takes care of passing along line/file/function
to the lldb_assert function. Let's call that instead of manually calling the
function.
Reland with changes: the test modified in this change originally failed
on a Debian/x86_64 builder, and I suspect the cause was that lldb looked
up the line location for an artificial frame by subtracting 1 from the
frame's address. For artificial frames, the subtraction must not happen
because the address is already exact.
---
lldb currently guesses the address to use when creating an artificial
frame (i.e., a frame constructed by determining the sequence of (tail)
calls which must have happened).
Guessing the address creates problems -- use the actual address provided
by the DW_AT_call_pc attribute instead.
Depends on D76336.
rdar://60307600
Differential Revision: https://reviews.llvm.org/D76337
Summary:
Currently we only log in debug builds but I don't see why we would do this as this is neither
expensive and seems useful.
I looked into the git history of this code and it seems originally there was also an assert here
and the logging here was the #else branch branch for non-Debug builds.
Reviewers: #lldb, labath
Reviewed By: labath
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D76698
This reverts commit 6905394d15. The
changed test is failing on Debian/x86_64, possibly because lldb is
subtracting an offset from the DW_AT_call_pc address used for the
artificial frame:
http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/7171/steps/test/logs/stdio
/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm-project/lldb/test/API/functionalities/tail_call_frames/unambiguous_sequence/main.cpp:6:17: error: CHECK-NEXT: expected string not found in input
// CHECK-NEXT: frame #1: 0x{{[0-9a-f]+}} a.out`func3() at main.cpp:14:3 [opt] [artificial]
^
<stdin>:3:2: note: scanning from here
frame #1: 0x0000000000401127 a.out`func3() at main.cpp:13:4 [opt] [artificial]
Summary:
These two variables are only incremented under LLDB_CONFIGURATION_DEBUG but their
value is always logged when verbose lldb formatter logging is enabled, which causes that our
cache hit/miss log looks like this in non-Debug builds:
```
Cache hits: 0 - Cache Misses: 0
...
Cache hits: 0 - Cache Misses: 0
...
Cache hits: 0 - Cache Misses: 0
```
This just always increments those two counters independent of build mode.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D76687
Summary:
Dumping the frame using the user-set format could cause that a debug LLDB doesn't behave as a release LLDB,
which could potentially break replaying a reproducer.
Also it's kinda strange that the frame format set by the user is used in the internal log output.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D76685
lldb currently guesses the address to use when creating an artificial
frame (i.e., a frame constructed by determining the sequence of (tail)
calls which must have happened).
Guessing the address creates problems -- use the actual address provided
by the DW_AT_call_pc attribute instead.
Depends on D76336.
rdar://60307600
Differential Revision: https://reviews.llvm.org/D76337
Summary:
This seems only useful for debugging and it's just plainly printf'ing to the console instead
of some log, so let's remove this.
Reviewers: #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D76699
Adrian Prantl