Clean up format string warnings in ValueObjectSyntheticFilter.cpp to explictly cast "%p" params to void *`
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22923
llvm-svn: 277016
This finally removes the use of the Mutex and Condition classes. This is an
intricate patch as the Mutex and Condition classes were tied together.
Furthermore, many places had slightly differing uses of time values. Convert
timeout values to relative everywhere to permit the use of
std::chrono::duration, which is required for the use of
std::condition_variable's timeout. Adjust all Condition and related Mutex
classes over to std::{,recursive_}mutex and std::condition_variable.
This change primarily comes at the cost of breaking the TracingMutex which was
based around the Mutex class. It would be possible to write a wrapper to
provide similar functionality, but that is beyond the scope of this change.
llvm-svn: 277011
"Incorrect" file name seen on Android whene the main executable is
called "app_process32" (or 64) but the linker specifies the package
name (e.g. com.android.calculator2). Additionally it can be present
in case of some linker bugs.
This CL adds logic to try to fetch the correct file name from the proc
file system based on the base address sepcified by the linker in case
we are failed to load the module by name.
Differential revision: http://reviews.llvm.org/D22219
llvm-svn: 276411
They will dump pretty-print (indentation, extra whitepsace) by default.
I'll make a change to ProcessGDBRemote soon so it stops sending JSON strings
to debugserver pretty-printed; it's unnecessary extra bytes being sent between
the two.
llvm-svn: 276079
Background: symbols and functions can be looked up by full mangled name and by basename. SymbolFile and ObjectFile are expected to be able to do the lookups based on full mangled name or by basename, so when the user types something that is incomplete, we must be able to look it up efficiently. For example the user types "a:🅱️:c" as a symbol to set a breakpoint on, we will break this down into a 'lookup "c"' and then weed out N matches down to just the ones that match "a:🅱️:c". Previously this was done manaully in many functions by calling Module::PrepareForFunctionNameLookup(...) and then doing the lookup and manually pruning the results down afterward with duplicated code. Now all places use Module::LookupInfo to do the work in one place.
This allowed me to fix the name lookups to look for "func" with eFunctionNameTypeFull as the "name_type_mask", and correctly weed the results:
"func", "func()", "func(int)", "a::func()", "b::func()", and "a:🅱️:func()" down to just "func", "func()", "func(int)". Previously we would have set 6 breakpoints, now we correctly set just 3. This also extends to the expression parser when it looks up names for functions it needs to not get multiple results so we can call the correct function.
<rdar://problem/24599697>
llvm-svn: 275281
The issue was we have two global variables: one that contains a DebuggerList pointer and one that contains a std::mutex pointer. These get initialized in Debugger::Initialize(), and everywhere that uses these does:
if (g_debugger_list_ptr && g_debugger_list_mutex_ptr)
{
std::lock_guard<std::recursive_mutex> guard(*g_debugger_list_mutex_ptr);
// do work while mutex is locked
}
Debugger::Terminate() was deleting and nulling out g_debugger_list_ptr which meant we had a race condition where someone might do the if statement and it evaluates to true, then another thread calls Debugger::Terminate() and deletes and nulls out g_debugger_list_ptr while holding the mutex, and another thread then locks the mutex and tries to use g_debugger_list_ptr. The fix is to just not delete and null out the g_debugger_list_ptr variable.
llvm-svn: 275119
This feature was added to solve a lookup problem in expressions when local variables
shadow ivars. That solution requires fully realizing all local variables to evaluate
any expression, and can cause significant performance problems when evaluating
expressions in frames that have many complex locals.
Until we get a better solution, this setting mitigates the problem when you don't
have local variables that shadow ivars.
<rdar://problem/27226122>
llvm-svn: 274783
"frame variable" and "target variable" are trying to emulate the expression parser when doing things like:
(lldb) frame variable &my_struct.my_bitfield
And since the expression parser doesn't allow this, we shouldn't allow "frame variable" or "target variable" to succeed.
<rdar://problem/27208607>
llvm-svn: 274703
- if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop;
- but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point
For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue
This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself
This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval)
Fixes rdar://26480007
llvm-svn: 274683
settings or raise no error if not found.
From time to time it is useful to add some setting to work around or enable
a transitory feature. We've been reluctant to remove them later because then
we will break folks .lldbinit files. With this change you can add an "experimental"
node to the settings. If you later decide you want to keep the option, just move
it to the level that contained the "experimental" setting and it will still be
found. Or just remove it - setting it will then silently fail and won't halt
the .lldbinit file execution.
llvm-svn: 274593
In Address.cpp, we were asking for the lldb::eSymbolContextVariable to be resolved, yet we weren't using the variable. This code gets called when disassembling and can cause the manual creation of all global variables variables which can take minutes. Removing eSymbolContextVariable allows disassembly to not create these long pauses.
In Module.cpp, if someone only specified the lldb::eSymbolContextVariable flag, we would not look into a module's debug info, now we will.
<rdar://problem/26907449>
llvm-svn: 273307
In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly.
llvm-svn: 272276
If users call "static void lldb::SBDebugger::Terminate()" we will clean up the debugger list, and users can individually destroy debugger instances with "static void lldb::SBDebugger::Destroy(SBDebugger &)". But if we let the C++ destructor chain tear down this list, other threads that might still be running as the main thread exits can now crash if they access the debugger list. We stop this by leaking the debugger list and its mutex.
<rdar://problem/26372169>
llvm-svn: 270869
On Darwin if a mmap file is code signed and the code signature is invalid, it used to crash. If we specify the MAP_RESILIENT_CODESIGN mmap flag when mapping a file for reading, we can avoid crashing.
Another mmap flag named MAP_RESILIENT_MEDIA allows us to survive if we mmap files that are on removable media like network servers or removable hard drives. If a file was mapped and later the media that had the file became unavailable, we would crash when we would touch the next page that wasn't paged in. Now it will return zeroes and stop of from us from crashing.
<rdar://problem/25918698>
llvm-svn: 270254
Summary: One of the cases handled by ValueObjectChild::UpdateValue() uses the entire width of the parent's scalar value as the size of the child, and extracts the child by calling Scalar::ExtractBitfield(). This seems valid but APInt::trunc(), APInt::sext() and APInt::zext() assert that the bit field must not have the same size as the parent scalar. Replacing those calls with sextOrTrunc(), zextOrTrunc(), sextOrSelf() and zextOrSelf() fixes the assertion failures.
Reviewers: uweigand, labath
Subscribers: labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D20355
llvm-svn: 270062
This is a pretty straightforward first pass over removing a number of uses of
Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there
are interfaces which take Mutex::Locker & to lock internal locks. This patch
cleans up most of the easy cases. The only non-trivial change is in
CommandObjectTarget.cpp where a Mutex::Locker was split into two.
llvm-svn: 269877
The main issues were:
- Listeners recently were converted over to used by getting a shared pointer to a listener. And when they listened to broadcasters they would get a strong reference added to them meaning the listeners would never go away. This caused memory usage to increase and would cause performance issue if many steps were done.
- The lldb_private::Process private state thread had an issue where if a "stop" contol signal was attempted to be sent to that thread, it could end up not responding in 2 seconds and end up getting cancelled which might cause us to cancel a thread that had a mutex locked and it would deadlock the test.
This change makes broadcasters hold onto weak references to listeners. It also fixes some bad threading code that had races inside of it by making the m_events_mutex be non-recursive and getting rid of fragile use of a Predicate<bool> to say that new events are available, and replacing it with using the m_events_mutex with a new m_events_condition to control access to the events in a safer way.
The private state thread now uses a safer way to communicate that the control event has been received by the private state thread: it makes a EventDataReceipt instance that it attaches to the event that sends the control to the private state thread and used this to synchronize the fact that the private state thread has received the event instead of using a Predicate<bool> to convey the info. When the signal event is received, it will pull the event off of the queue in the private state thread and cause the EventData::DoOnRemoval() to be called, which will signal that the event has been received. This cleans up the signal delivery notification so it doesn't rely on a member variable of the process class to convey the info.
std::shared_ptr<EventDataReceipt> event_receipt_sp(new EventDataReceipt());
m_private_state_control_broadcaster.BroadcastEvent(signal, event_receipt_sp);
<rdar://problem/26256353> Listeners are being kept around longer than they should be due to recent changs
<rdar://problem/26256258> Private process state thread can be cancelled and cause deadlocks in test suite
llvm-svn: 269377
Patch by Nitesh Jain.
Summary: The ArchSpec::m_flags will be set based on ELF flag ABI.
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits, mohit.bhakkad, sagar, jaydeep, bhushan
Differential: D18858
llvm-svn: 269181
Clear() log message was claiming it was the destructor, which had me very confused when looking
at the log messages. Fix the message, and add a log message to the real destructor.
Also noticed that the destructor was needlessly locking the broadcaster mutex (as Clear was
locking it again anyway), so remove that as well.
llvm-svn: 269058
"Allow LanguageRuntimes to return an error if they fail in the course of dynamic type discovery
This is not meant to report that a value doesn't have a dynamic type - it is only meant as a mechanism to propagate actual type discovery issues (e.g. malformed type metadata for languages that have such a notion)
This information is used by ValueObjectDynamic to set its own m_error, which is a fairly sharp and heavyweight tool to begin with
For the time being, this is an architectural improvement but a practical no-op as no existing runtimes are actually setting errors"
I need to think about what I want to do in this space more carefully - this attempt might be too heavy of a hammer for the nail I am trying to fix, and I don't want to leave it in while I ponder
llvm-svn: 268686
This is not meant to report that a value doesn't have a dynamic type - it is only meant as a mechanism to propagate actual type discovery issues (e.g. malformed type metadata for languages that have such a notion)
This information is used by ValueObjectDynamic to set its own m_error, which is a fairly sharp and heavyweight tool to begin with
For the time being, this is an architectural improvement but a practical no-op as no existing runtimes are actually setting errors
llvm-svn: 268591
We don't want a mutex in debugger as it will cause A/B locking issues with the lldb_private::Target's mutex, but we do need to stop two threads from doing Debugger::Clear at the same time. We have seen issues with this with the C++ global destructor chain where the global debugger list is being destroyed and the Debugger::~Debugger() is calling it while another thread was in the middle of running that function.
<rdar://problem/26098913>
llvm-svn: 268563
Summary:
AdbClient was attempting to handle the case where the socket input arrived in pieces, but it was
failing to handle the case where the connection was closed before that happened. In this case, it
would just spin in an infinite loop calling Connection::Read. (This was also the cause of the
spurious timeouts on the darwin->android buildbot. The exact cause of the premature EOF remains
to be investigated, but is likely a server bug.)
Since this wait-for-a-certain-number-of-bytes seems like a useful functionality to have, I am
moving it (with the infinite loop fixed) to the Connection class, and adding an
appropriate test for it.
Reviewers: clayborg, zturner, ovyalov
Subscribers: tberghammer, danalbert, lldb-commits
Differential Revision: http://reviews.llvm.org/D19533
llvm-svn: 268380
This reverts commit r267833 as it breaks the build. It looks like some work in progress got
committed together with the actual fix, but I'm not sure which one is which, so I'll revert the
whole patch and let author resumbit it after fixing the build error.
llvm-svn: 267861
In templated const functions, trying to run an expression would produce the
error
error: out-of-line definition of '$__lldb_expr' does not match any declaration in 'foo'
member declaration does not match because it is const qualified
error: 1 error parsing expression
which is no good. It turned out we don't actually need to worry about "const,"
we just need to be consistent about the declaration of the expression and the
FunctionDecl we inject into the class for "this."
Also added a test case.
<rdar://problem/24985958>
llvm-svn: 267833
rL267291 introduces a lot regression on arm-linux LLDB testsuite.
This patch fixes half of them. I am merging it under already revied android counterpart.
Another patch fixing rest of the issue will follow this commit.
Differential revision: http://reviews.llvm.org/D19480
llvm-svn: 267508
Recommit modified version of r266311 including build bot regression fix.
This differs from the original r266311 by:
- Fixing Scalar::Promote to correctly zero- or sign-extend value depending
on signedness of the *source* type, not the target type.
- Omitting a few stand-alone fixes that were already committed separately.
llvm-svn: 266422
Currently, the DataExtractor::GetMaxU64Bitfield and GetMaxS64Bitfield
routines assume the incoming "bitfield_bit_offset" parameter uses
little-endian bit numbering, i.e. a bitfield_bit_offset 0 refers to
a bitfield whose least-significant bit coincides with the least-
significant bit of the surrounding integer.
On many big-endian systems, however, the big-endian bit numbering
is used for bit fields. Here, a bitfield_bit_offset 0 refers to
a bitfield whose most-significant bit conincides with the most-
significant bit of the surrounding integer.
Now, in principle LLDB could arbitrarily choose which semantics of
bitfield_bit_offset to use. However, there are two problems with
the current approach:
- When parsing DWARF, LLDB decodes bit offsets in little-endian
bit numbering on LE systems, but in big-endian bit numbering
on BE systems. Passing those offsets later on into the
DataExtractor routines gives incorrect results on BE.
- In the interim, LLDB's type layer combines byte and bit offsets
into a single number. I.e. instead of recording bitfields by
specifying the byte offset and byte size of the surrounding
integer *plus* the bit offset of the bit field within that field,
it simply records a single bit offset number.
Now, note that converting from byte offset + bit offset to a
single offset value and back is well-defined if we either use
little-endian byte order *and* little-endian bit numbering,
or use big-endian byte order *and* big-endian bit numbering.
Any other combination will yield incorrect results.
Therefore, the simplest approach would seem to be to always use
the bit numbering that matches the system byte order. This makes
storing a single bit offset valid, and makes the existing DWARF
code correct. The only place to fix is to teach DataExtractor
to use big-endian bit numbering on big endian systems.
However, there is only additional caveat: we also get bit offsets
from LLDB synthetic bitfields. While the exact semantics of those
doesn't seem to be well-defined, from test cases it appears that
the intent was for the user-provided synthetic bitfield offset to
always use little-endian bit numbering. Therefore, on a big-endian
system we now have to convert those to big-endian bit numbering
to remain consistent.
Differential Revision: http://reviews.llvm.org/D18982
llvm-svn: 266312
Luke Drummond