| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
rdar://problem/25767901
llvm-svn: 275199
|
|
|
|
| |
llvm-svn: 275198
|
|
|
|
|
|
|
|
|
|
| |
Loading a dynamic library can take quite a long time, since it triggers a number of
shared-library-event stops for dependent libraries. This is especially true for remote targets
due to communication latency. Increase the default 500ms timeout to account for that.
Committing as obvious.
llvm-svn: 275185
|
|
|
|
|
|
| |
10ms does not seem to be enough all the time, go to 50.
llvm-svn: 275175
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
LLDBTestResult.hardMarkAsSkipped marked the whole class as skipped when the first class in the
test failed the category check. This meant that subsequent tests in the same class did not run
even if they were passing the category filter. Fix that.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22213
llvm-svn: 275173
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Process::SetExitStatus was popping the process io handler and resetting m_process_input_reader
shared pointer, which is not a safe thing to do as the function is called asynchronously and
other threads may be accessing the member variable. (E.g. if the process terminates really
quickly, the private state thread might only be in the process of pushing the handler on the
stack. Sometimes, this leads to deadlock, as the shared pointer's state gets corrupted by the
concurrent access.
Since the IOHandler will be popped anyway in Process:HandleProcessStateChangedEvent when the
exited event gets processed, doing the same in SetExitStatus seems to be unnecessary.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22209
llvm-svn: 275165
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
void typedefs do not have a DW_AT_type attribute, so we end up with an empty encoding_uid
variable. These don't need to be looked up and trying to look that will assert in a debug build.
Reviewers: clayborg
Subscribers: lldb-commits, tberghammer
Differential Revision: http://reviews.llvm.org/D22218
llvm-svn: 275164
|
|
|
|
|
|
|
|
|
| |
is passed a ModuleSpec with a UUID, it won't accept a file it finds
with a matching FileSpec & ArchSpec, but with a different UUID.
<rdar://problem/27258864>
llvm-svn: 275151
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: tfiala, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22234
llvm-svn: 275140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Some thread plans have public contructors, some others have protected
constructors with friend classes. Not sure how these were determined,
but this thread plan is going to be required to implement trampoline
step-through on Windows.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22230
llvm-svn: 275139
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is already done when building for linux with the CMake build
system. This functionality disappeared recently when some of the build
scripts used by the xcode build system changed.
Reviewers: tfiala, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22233
llvm-svn: 275134
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Debugger::Terminate().
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
|
|
|
|
|
|
| |
as an existing alias (or rather, one could but the results of invoking the command were far from satisfactory)
llvm-svn: 275080
|
|
|
|
|
|
|
|
|
|
| |
If LLDB reads some incorrect input form /proc/<pid>/maps then it
should report an error instead of assert-ing as we don't want to
crash in case of an incorrect maps file.
Differential revision: http://reviews.llvm.org/D22211
llvm-svn: 275060
|
|
|
|
|
|
|
|
|
|
| |
sure that <new-path> exists before accepting it as a remapping.
We had some clients that had added old source paths remappings to their .lldbinit files and they were causing trouble at a later date. This fix should help mitigate these issues.
<rdar://problem/26358860>
llvm-svn: 274948
|
|
|
|
|
|
| |
values can refer back to their parents
llvm-svn: 274901
|
|
|
|
|
|
| |
http://reviews.llvm.org/D22081
llvm-svn: 274895
|
|
|
|
|
|
|
| |
This is just an SB API way of doing "thread return -x".
<rdar://problem/27110360>
llvm-svn: 274822
|
|
|
|
|
|
|
|
|
|
| |
type that is typedef'ed is a declaration. This fixes the following bugs:
<rdar://problem/26870890> [PR28156] TestWithModuleDebugging.py: failing on macOS
https://llvm.org/bugs/show_bug.cgi?id=27412
https://llvm.org/bugs/show_bug.cgi?id=28156
llvm-svn: 274809
|
|
|
|
|
|
|
|
| |
attribute.
<rdar://problem/26321896>
llvm-svn: 274788
|
|
|
|
|
|
|
|
|
| |
If it does, calling AddInitializerToDecl will crash, so we should
abort the result synthesis in this case.
<rdar://problem/27205383>
llvm-svn: 274787
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expressions.
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
|
|
|
|
|
|
|
|
|
|
|
| |
When multiple Android devices are attached, the default behaviour of ADB
is to resolve a device number based on the presence of ANDROID_SERIAL if
the serial number is not explicitly passed by the -s parameter. This patch
emulates that behaviour in lldb's ADB platform connector
Differential Revision: http://reviews.llvm.org/D22052
llvm-svn: 274776
|
|
|
|
|
|
|
| |
On android M it can happen that we get a ETXTBSY, when we try to launch the inferior. Sleeping
and retrying should help us get more stable results.
llvm-svn: 274763
|
|
|
|
|
|
| |
remote targets need a bit more time to get their act together
llvm-svn: 274762
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The issue arises due to the wrong unwinder used for the first
stack frame, where the default unwinder returns erroneous frame
whereas the fallback would have given the correct frame had it
been used.
The following fix consists of two parts ->
1) The first part changes the unwinding strategy, earlier the
default unwinder was used to get 2 more stack frames and if it
failed a fallback unwinder was used. Now we try to obtain as many
frames (max 10) as we can get from default unwinder and also
fallback unwinder and use the one that gives more number of frames.
2) Normally unwindplans are assosciated with functions and the
row to be used is obtained from the offset (obtained from the low_pc
of the function symbol). Sometimes it may occur that the unwindplan
is assosciated to the complete Elf section in which case the offset
calculation would be wrong as the debugger uses the same offset originally
obtained from the function symbol. Hence this offset is recalculated.
Reviewers: tberghammer, lldb-commits, labath, jasonmolenda
Subscribers: jingham
Differential Revision: http://reviews.llvm.org/D21221
llvm-svn: 274750
|
|
|
|
| |
llvm-svn: 274743
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch fills in the implementation of GetMemoryRegions() on the Linux and Mac OS core file implementations of lldb_private::Process (ProcessElfCore::GetMemoryRegions and ProcessMachCore::GetMemoryRegions.) The GetMemoryRegions API was added under: http://reviews.llvm.org/D20565
The patch re-uses the m_core_range_infos list that was recently added to implement GetMemoryRegionInfo in both ProcessElfCore and ProcessMachCore to ensure the returned regions match the regions returned by Process::GetMemoryRegionInfo(addr_t load_addr, MemoryRegionInfo ®ion_info).
Reviewers: clayborg
Subscribers: labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D21751
llvm-svn: 274741
|
|
|
|
|
|
|
|
|
|
|
|
| |
os name and version # from the mach-o binary as it scans the
header/load commands from memory and sends the details back
in the jGetLoadedDynamicLibrariesInfos response. lldb isn't
using these fields yet but I have a suspicion I'm going to
need them soon.
<rdar://problem/25251243>
llvm-svn: 274725
|
|
|
|
|
|
|
|
|
|
|
|
| |
to find the solibs loaded in a process. Support two new ways of
sending the jGetLoadedDynamicLibrariesInfos packet to debugserver
and add a new jGetSharedCacheInfo packet. Update the documentation
for these packets as well. The changes to lldb to use these will
be a separate commit.
<rdar://problem/25251243>
llvm-svn: 274718
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of bitfields.
"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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bits from file memory.
Bitfields were not correctly describing their offsets within the integer that they are contained within. If we had a bitfield like:
struct MyStruct {
uint32_t a:8;
uint32_t b:8;
};
ClangASTContext::GetChildCompilerTypeAtIndex would say that child a and b had the following values in their respective ValueObjectChild objects:
name byte-size bit-size bit-offset byte-offset-from-parent
==== ========= ======== ========== =======================
"a" 4 8 0 0
"b" 4 8 0 1
So if we had a "MyStruct" at address 0x1000, we would end up reading 4 bytes from 0x1000 for "a", and 4 bytes from 0x1001 for "b". The fix for this is to fix the "child_byte_offset" and "child_bitfield_bit_offset" values returned by ClangASTContext::GetChildCompilerTypeAtIndex() so that now the table looks like:
name byte-size bit-size bit-offset byte-offset-from-parent
==== ========= ======== ========== =======================
"a" 4 8 0 0
"b" 4 8 8 0
Then we don't run into a problem when reading data from a file's section info using "target variable" before running. It will also stop us from not being able to display a bitfield values if the bitfield is in the last bit of memory before an unmapped region. (Like if address 0x1004 was unmapped and unreadable in the example above, if we tried to read 4 bytes from 0x1001, the memory read would fail and we wouldn't be able to display "b").
<rdar://problem/27208225>
llvm-svn: 274701
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
may be in a function that is non-ABI conformant, and the eh_frame
instructions correctly describe how to unwind out of this function,
but the assembly parsing / arch default unwind plans would be
incorrect.
This is to address a problem that Ravitheja Addepally reported in
http://reviews.llvm.org/D21221 - I wanted to try handling the problem
with this approach which I think may be more generally helpful,
Ravitheja tested it and said it solves the problem on Linux/FreeBSD.
Ravi has a test case in http://reviews.llvm.org/D21221 that will
be committed separately.
Thanks for all the help on this one, Ravi.
llvm-svn: 274700
|
|
|
|
|
|
| |
functionality
llvm-svn: 274697
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
synthetic children caching is a tricky area:
- 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
|
|
|
|
|
|
| |
http://reviews.llvm.org/D22029
llvm-svn: 274638
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D22040
llvm-svn: 274635
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We are seeing infrequent failures to launch the inferior process on android. The failing call
seems to be execve(). This adds more logging to see the actual error reported by the call.
Reviewers: tberghammer
Subscribers: tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D22039
llvm-svn: 274624
|
|
|
|
|
|
| |
of the expression we're evaluating.
llvm-svn: 274621
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D21984
llvm-svn: 274617
|
|
|
|
| |
llvm-svn: 274594
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
it works for DWARF in .o files on Darwin.
I changed "m_is_optimized" in lldb_private::CompileUnit over to be a lldb::LazyBool so that it can be set to eLazyBoolCalculate if it needs to be parsed later. With SymbolFileDWARFDebugMap, we don't actually open the DWARF in the .o files for each compile unit until later, and we can't tell if a compile unit is optimized ahead of time. So to avoid pulling in all .o right away just so we can answer the questions of "is this compile unit optimized" we defer it until a point where we will have the compile unit parsed.
<rdar://problem/26068360>
llvm-svn: 274585
|
|
|
|
|
|
|
|
| |
Also added a testcase.
<rdar://problem/22786569>
llvm-svn: 274580
|
|
|
|
|
|
|
|
| |
right thing.
https://llvm.org/bugs/show_bug.cgi?id=28428
llvm-svn: 274568
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
One of the tests there does not work with gcc, so I'm spinning that off into a separate test, so
that we can XFAIL it with more granularity.
I am also renaming the test to reflect the fact that it no longer tests only integer arguments.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D21923
llvm-svn: 274505
|
|
|
|
|
|
|
|
|
|
|
| |
These are artifical symbols inside android oat files without any value
for the user while causing a significant perfoamce hit inside the
unwinder. We were already ignoring it inside system@framework@boot.oat
bot they have to be ignored in every oat file. Considering that oat
files are only used on android this have no effect on any other
platfrom.
llvm-svn: 274500
|
|
|
|
|
|
|
| |
It is sufficient to set the handeler to SIG_IGN, to get the desired behaviour. Also, the handler
calling a lot of signal-unsafe functions.
llvm-svn: 274499
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a slightly reworked version of D16322, which I had reverted because it did not do what it
advertised. Differences from the previous version are:
- moved the code for cleaning up the remote working dir to a later point as it was removing the
log file before we could get to it.
- specialised log downloading code for gdb-remote tests is not needed, as this will cover that
use case as well.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D21898
llvm-svn: 274491
|
|
|
|
| |
llvm-svn: 274490
|