As is common with curses apps, this allows to redraw everything
in case something corrupts the screen. Apparently key modifiers
are difficult with curses (curses FAQ it "doesn't do that"),
thankfully Ctrl+key are simply control characters, so it's
(ascii & 037) => 12.
Differential Revision: https://reviews.llvm.org/D84972
Let's just return a std::string to make this safe. formatv seemed overkill for formatting
the return values as they all just append an integer value to a constant string.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D84505
'd' would be much better used for up/down shortcuts, and this also removes
the possibility of ruining the whole debugging session by accidentally
hitting 'd' or 'k'. Also change menu to have both 'detach and resume'
and 'detach suspended' to make it clear which one is which. See
discussion at https://reviews.llvm.org/D68541 .
Differential Revision: https://reviews.llvm.org/D68908
This cleanup patch unifies all methods called GetByteSize() in the
ValueObject hierarchy to return an optional, like the methods in
CompilerType do. This means fewer magic 0 values, which could fix bugs
down the road in languages where types can have a size of zero, such
as Swift and C (but not C++).
Differential Revision: https://reviews.llvm.org/D84285
This re-lands the patch with bogus :m_byte_size(0) initalizations removed.
This cleanup patch unifies all methods called GetByteSize() in the
ValueObject hierarchy to return an optional, like the methods in
CompilerType do. This means fewer magic 0 values, which could fix bugs
down the road in languages where types can have a size of zero, such
as Swift and C (but not C++).
Differential Revision: https://reviews.llvm.org/D84285
ConstString is essentially trivially copyable yet it has a user defined
copy constructor that copies its one member pointer. Remove it so it
qualifies as trivial in the eyes of the compiler.
This also fixes two unused variable warnings now that the compiler knows
that the constructor has no side-effects.
Differential revision: https://reviews.llvm.org/D84440
This patch has no effect for C and C++. In more dynamic languages,
such as Objective-C and Swift GetByteSize() needs to call into the
language runtime, so it's important to pass one in where possible. My
primary motivation for this is some work I'm doing on the Swift
branch, however, it looks like we are also seeing warnings in
Objective-C that this may resolve. Everything in the SymbolFile
hierarchy still passes in nullptrs, because we don't have an execution
context in SymbolFile, since SymbolFile transcends processes.
Differential Revision: https://reviews.llvm.org/D84267
Summary:
When modules reference each other (which happens for example with the different
modules LLDB loads when debugging -gmodules-compiled binaries), just iterating
over the module list once isn't good enough to find all orphans. Any removed
modules in the module list will also clear up the shared pointers they hold to
other modules, so after any module was removed from the list, LLDB should
iterate again and check if any additional modules can no be safely deleted.
This is currently causing that many gmodules tests are not cleaning up all
allocated modules which causes cleanup asserts to fail (right now these asserts
just mark the test as unsupported, but after D83865 the tests will start
failing).
Reviewers: aprantl, clayborg, JDevlieghere
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D84015
Summary:
This patch extends the ModuleSpec class to include a
DataBufferSP which contains the module data. If this
data is provided, LLDB won't try to hit the filesystem
to create the Module, but use only the data stored in
the ModuleSpec.
Reviewers: labath, espindola
Subscribers: emaste, MaskRay, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D83512
Summary: Just unifying all that copy-pasted code.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D83662
The problem is that synthetic value objects can sometimes represent objects in target memory, and other times they might be made up wholly in lldb memory, with pointers from one synthetic object to another, and so the ValueObjectVariable computation was not appropriate.
This patch delegates the computation to the root of the ValueObject in question. That solves the problem for ValueObjectVariable while not messing up the computation for ValueObjectConstResult or ValueObjectSynthetic.
Differential Revision: https://reviews.llvm.org/D83450
The patch fixes a crash in ValueObject::CreateChildAtIndex caused by a
null pointer dereferencing. This is a corner case that is happening when
trying to dereference a variable with an incomplete type, and this same
variable doesn't have a synthetic value to get the child ValueObject.
If this happens, lldb will now return a null pointer that will results
in an error message.
rdar://65181171
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Summary:
The Scalar class claims to follow the C type conversion rules. This is
true for the Promote function, but it is not true for the implicit
conversions done in the getter methods.
These functions had a subtle bug: when extending the type, they used the
signedness of the *target* type in order to determine whether to do
sign-extension or zero-extension. This is not how things work in C,
which uses the signedness of the *source* type. I.e., C does
(sign-)extension before it does signed->unsigned conversion, and not the
other way around.
This means that: (unsigned long)(int)-1
is equal to (unsigned long)0xffffffffffffffff
and not (unsigned long)0x00000000ffffffff
Unsurprisingly, we have accumulated code which depended on this
inconsistent behavior. It mainly manifested itself as code calling
"ULongLong/SLongLong" as a way to get the value of the Scalar object in
a primitive type that is "large enough". Previously, the ULongLong
conversion did not do sign-extension, but now it does.
This patch makes the Scalar getters consistent with the declared
semantics, and fixes the couple of call sites that were using it
incorrectly.
Reviewers: teemperor, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D82772
Summary:
LLVM is using its own isPrint/isSpace implementation that doesn't change depending on the current locale. LLDB should do the same
to prevent that internal logic changes depending on the set locale.
Reviewers: JDevlieghere, labath, mib, totally_not_teemperor
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D82175
Summary:
TerminalSizeChanged is called from our SIGWINCH signal handler but the
IOHandlerEditline currently doesn't check if we are actually using the real
editline backend. If we're not using the real editline backend, `m_editline_up`
won't be set and `IOHandlerEditline::TerminalSizeChanged` will access
the empty unique_ptr. In a real use case we don't use the editline backend
when we for example read input from a file. We also create some temporary
IOHandlerEditline's during LLDB startup it seems that are also treated
as non-interactive (apparently to read startup commands).
This patch just adds a nullptr check for`m_editline_up` as we do in the rest of
IOHandlerEditline.
Fixes rdar://problem/63921950
Reviewers: labath, friss
Reviewed By: friss
Subscribers: abidh, JDevlieghere
Differential Revision: https://reviews.llvm.org/D81729
This replaces the (only) call to llvm::sys::fs::openFileForWrite with
FileSystem::Open. This guarantees that we include log files in the
reproducers.
Differential revision: https://reviews.llvm.org/D81499
Summary:
Objective-C names are stored in m_demangled, not in m_mangled. The
method in the condition will never return true.
Differential Revision: https://reviews.llvm.org/D79823
Summary: We are not doing this very often, but sometimes it's convenient when I can just << ConstStrings into llvm::errs() during testing.
Reviewers: labath, JDevlieghere
Reviewed By: labath, JDevlieghere
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D80310
Demangling Itanium symbols either consumes the whole input or fails,
but Microsoft symbols can be successfully demangled with just some
of the input.
Add an outparam that enables clients to know how much of the input was
consumed, and use this flag to give llvm-undname an opt-in warning
on partially consumed symbols.
Differential Revision: https://reviews.llvm.org/D80173
This patch improves data formatting for CFDictionaryRef and CFSetRef.
It uses the same data-formatter as NSCFDictionaries and NSCFSets introduced
previously but did require some adjustments in Core::ValueObject.
Since the "Ref" types are opaque pointers to the actual CF containers, if the
value object has a synthetic value, lldb will use the opaque pointer's pointee
type to create the new ValueObjectChild needed to dereference the ValueObject.
This allows the "Ref" types to behaves the same as CF containers when used with
the `frame variable` command, the SBAPI or in Xcode's variable inspector.
This patch also adds support for incomplete types in ValueObject.
rdar://53104287
Differential Revision: https://reviews.llvm.org/D79554
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Summary:
The comment in the Editine.h header made it sound like editline was
just unable to handle terminal resizing. We were not ever telling
editline that the terminal had changed size, which might explain why
it wasn't working.
This patch threads a `TerminalSizeChanged()` callback through the
IOHandler and invokes it from the SIGWINCH handler in the driver. Our
`Editline` class already had a `TerminalSizeChanged()` method which
was invoked only when editline was configured.
This patch also changes `Editline` to not apply the changes right away
in `TerminalSizeChanged()`, but instead defer that to the next
character read. During my testing, it happened once that the signal
was received while our `ConnectionFileDescriptor::Read` was allocating
memory. As `el_resize` seems to allocate memory too, this crashed.
Reviewers: labath, teemperor
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79654
Summary:
`CalculateSyntheticValue` and `GetSyntheticValue` have a `use_synthetic` parameter
that makes the function do nothing when it's false. We obviously always pass true
to the function (or check that the value we pass is true), because there really isn't
any point calling with function with a `false`. This just removes all of this.
Reviewers: labath, JDevlieghere, davide
Reviewed By: davide
Subscribers: davide
Differential Revision: https://reviews.llvm.org/D79568
We currently rely on the TypeSystem implementation to initialize this value
with 0 in the GetChildCompilerTypeAtIndex call below. Let's just initialize
this variable like the rest.
When debugging a remote platform, the platform you get from
GetPlatformForArchitecture doesn't inherit from PlatformDarwin.
HostInfoMacOSX seems like the right place to have a global store of
local paths.
Differential Revision: https://reviews.llvm.org/D79364
When debugging from a SymbolMap the creation of CompileUnits for the
individual object files is so lazy that RegisterXcodeSDK() is not
invoked at all before the Swift TypeSystem wants to read it. This
patch fixes this by introducing an explicit
SymbolFile::ParseXcodeSDK() call that can be invoked deterministically
before the result is required.
<rdar://problem/62532151+62326862>
https://reviews.llvm.org/D79273
Calling Disconnect while the read thread is running is racy because the
thread can also call Disconnect. This is a follow-up to b424b0bf, which
reorders other occurences of Disconnect/StopReadThread I can find, and also
adds an assertion to guard against new occurences being introduced.
Summary:
...and replace it with m_last_file_spec instead.
When Source Cache is enabled, the value stored in m_last_file_sp is
already in the Source Cache, and caching it again in SourceManager
brings no extra benefit. All we need is to "remember" the last used
file, and FileSpec can serve the same purpose.
When Source Cache is disabled, the user explicitly requested no caching
of source files, and therefore, m_last_file_sp should NOT be used.
Bug: llvm.org/PR45310
Depends on D76805.
Reviewers: labath, jingham
Reviewed By: jingham
Subscribers: labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76806
Summary:
Lookup and subsequent insert was done using uninitialized
FileSpec object, which caused the cache to be a no-op.
Bug: llvm.org/PR45310
Depends on D76804.
Reviewers: labath, JDevlieghere
Reviewed By: labath
Subscribers: mgorny, jingham, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76805
Summary:
LLDB memory-maps large source files, and at the same time, caches
all source files in the Source Cache.
On Windows, memory-mapped source files are not writeable, causing
bad user experience in IDEs (such as errors when saving edited files).
IDEs should have the ability to disable the Source Cache at LLDB
startup, so that users can edit source files while debugging.
Bug: llvm.org/PR45310
Reviewers: labath, JDevlieghere, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76804
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
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
