| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
Some watchpoint tests fail on aarch64-linux as it lacks support for intalling watchpoints which are not alligned at 8bytes boundary.
Marking them as xfail for now.
llvm-svn: 269187
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
test_listener_event_process_state checks for Threads
and Frames in the multithreaded_queue. The listener_func has
more computational load, which may be latter executed than the
pop leading to the failure. This patch tries to only check for
frames in listener_func as presence of frames also confirms
prescence of threads and avoids the second push into the
multithreaded_queue.
Reviewers: lldb-commits, clayborg, labath
Differential Revision: http://reviews.llvm.org/D20091
llvm-svn: 269168
|
|
|
|
|
|
|
| |
Test uses x1 in breakpoint expression while objdump shows that x1 is never used in the code and may have random values.
Using x0 make sure that we are using a registe that will have a positive value and breakpoint expression will evaluate true atleast once.
llvm-svn: 269164
|
|
|
|
|
|
|
|
|
|
| |
reconstruct a compile unit or a function, but it still has a valid symbol - and it can use that in order to figure out the preferential language for lookups
This is not the right thing for all clients (notably the expression parser), so put it in type lookup specific code
Fixes rdar://problem/22422313
llvm-svn: 269095
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 269057
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
TestExitDuringStep was very rarely hanging on the buildbots. I can't be sure, but I believe this
was because of the fact that it declared its pseudo_barrier variable as "volatile int", which is
not sufficient to guarantee corectness (also, all other tests used atomic variables for this, and
they were passing reliably AFAIK). Besides switching to an atomic variable in this test as well,
I have also took this opportunity to unify all the copies of the pseudo_barrier code to a single
place to reduce the chance of this happening again.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20065
llvm-svn: 269025
|
|
|
|
|
|
|
| |
This tests both that we set the breakpoint on the right line, and that restricting by file
and/or the function, we get the right breakpoints.
llvm-svn: 269004
|
|
|
|
| |
llvm-svn: 268971
|
|
|
|
|
|
|
|
| |
IOHandlerLinesUpdated() does nothing, and IOHandlerIsInputComplete should be
implemented but isn't. This means that multiline expressions don't work. This
patch fixes that. Test case to follow in the next commit.
llvm-svn: 268970
|
|
|
|
|
|
| |
PR27687
llvm-svn: 268934
|
|
|
|
|
|
|
|
| |
NamespaceLookupTestCase.test_scope_lookup_before_using_with_run_command on linux
test appears to be passing now.
llvm-svn: 268923
|
|
|
|
|
|
|
| |
llvm::Error requires all errors to be handled. Simply checking the whether there was an error is
not enough, you have to actuall call handle(All)Errors, in case there was an error.
llvm-svn: 268906
|
|
|
|
|
|
|
|
| |
The IsValid calls can try to reconstruct the thread & frame, which can
take various internal locks. This can cause A/B locking issues with
the Target lock, so these calls need to that the Target lock.
llvm-svn: 268828
|
|
|
|
|
|
|
| |
Greg says he doesn't need these asserts anymore and since they cause occasional test suite
crashes, out they go.
llvm-svn: 268827
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
through line 0 code".
That's good 'cause it means all the different kinds of source line stepping won't leave user in the middle of
compiler implementation code or code inlined from odd places, etc. But it turns out that the compiler
also marks functions it MIGHT inline as all being of line 0. That would mean we single step through this code
instead of just stepping out. That is both inefficient, and more error prone 'cause these little nuggets tend
to be bits of hand-written assembly and the like and are hard to step through.
This change just checks and if the entire function is marked with line 0, we step out rather than step through.
<rdar://problem/25966460>
llvm-svn: 268823
|
|
|
|
| |
llvm-svn: 268802
|
|
|
|
|
|
|
| |
Remove the typedef and local structure which was unused. Fixes last of the new
clang warnings in the debugserver build. NFC.
llvm-svn: 268759
|
|
|
|
|
|
|
| |
Explicitly provide an initializer for the std::vector in the constructed type.
Addresses -Wmissing-field-initializers warnings from clang. NFC.
llvm-svn: 268758
|
|
|
|
|
|
|
| |
Remove the unnecessary use of std::move to permit the compiler to perform NVRO
instead. Fixes more warnings from clang. NFC.
llvm-svn: 268757
|
|
|
|
|
|
|
|
| |
Remove a couple of `default` cases from switches which are covered. This is
beneficial since it would allow the compiler to indicate when a new enum value
is added and the switch is not updated. Fixes some warnings from clang. NFC.
llvm-svn: 268756
|
|
|
|
|
|
|
| |
Perform explicit casts for the log message to address some `-Wformat-pedantic`
warnings from clang. NFC.
llvm-svn: 268755
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D19991
llvm-svn: 268750
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"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 change addresses a hang/segfault in TestEvents.py. The threads that
run the listener loops now do an SBListener.Clear() before they wrap up
their work. This prevents the test from trying to clean up the
SBListener too late.
There is a separate issue here which is that we should prevent this
clean-up time lock-up, but that is out of scope for this particular
change. I'd like to get these tests back and running the normal flow
rather than skipping them.
This addresses:
llvm.org/pr25924 (at least, the OS X side, although I suspect this will
also address Linux)
http://reviews.llvm.org/D19983
reviewed by: Jim Ingham
llvm-svn: 268653
|
|
|
|
|
|
|
| |
This was broken in the grand configuration change. Now
using -# works again.
llvm-svn: 268638
|
|
|
|
|
|
|
|
|
| |
The function only avaibleble when python is enabled. Guard the new call
in the Java plugin with LLDB_DISABLE_PYTHON until we can change
AddCXXSynthetic to be available in all case to get the build bots green
again.
llvm-svn: 268626
|
|
|
|
|
|
|
| |
now that the timeout actually means something, we see that sometimes adb is just really slow in
replying to the DONE packet during file push. Give it more time to complete.
llvm-svn: 268623
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D19540
llvm-svn: 268622
|
|
|
|
|
|
|
| |
the test should no longer crash, but we need to investigate why ToT clang still generates debug
info we don't understand.
llvm-svn: 268619
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
AdbClient would spin in a loop in ReadAllBytes in case the remote end was closed before reading
the requested number of bytes. Make sure we return an error in this case instead.
Reviewers: ovyalov
Subscribers: tberghammer, danalbert, lldb-commits
Differential Revision: http://reviews.llvm.org/D19916
llvm-svn: 268617
|
|
|
|
| |
llvm-svn: 268616
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We were trying to get a DWARFDIE from a CompileUnit belonging to a DWO file. However, this
function does not understand the die encoding used by the DWO files. Instead use GetDIE on the
SymbolFileDWARF, which is overriden in DWO to do the right thing.
Reviewers: clayborg, tberghammer
Subscribers: lldb-commits, ovyalov
Differential Revision: http://reviews.llvm.org/D19927
llvm-svn: 268615
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 268591
|
|
|
|
|
|
|
|
| |
not to log depending on whether the types log is enabled
This can prove helpful in debugging issues with that retrieval even if LLDB wasn't compiled with the magic macros defined
llvm-svn: 268587
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19943
llvm-svn: 268574
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Fixed semicolon placement in the lambda in the test itself.
2. Fixed lldbinline tests in general so that we don't attempt tests on platforms that don't use the given type of debug info. (For example, no DWO tests on Windows.) This fixes one of the two failures on Windows. (TestLambdas.py was the only inline test that wasn't XFailed or skipped on Windows.)
3. Set the error string in IRInterpreter::CanInterpret so that the caller doesn't print (null) instead of an explanation. I don't entirely understand the error, so feel free to suggest a better wording.
4. XFailed the test on Windows. The interpreter won't evaluate the lambda because the module has multiple function bodies. I don't exactly understand why that's a problem for the interpreter nor why the problem arises only on Windows.
Differential Revision: http://reviews.llvm.org/D19606
llvm-svn: 268573
|
|
|
|
| |
llvm-svn: 268566
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 268562
|
|
|
|
|
|
| |
<rdar://problem/25959792>
llvm-svn: 268559
|
|
|
|
|
|
|
| |
r268544 moves all PDB reading code into a pdb namespace,
so LLDB needs to be updated to take this into account.
llvm-svn: 268545
|
|
|
|
| |
llvm-svn: 268520
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
should not be used for this module -- for use when an ObjectFile
knows that it does not have meaningful or accurate function start
addresses.
More commonly, it is not clear that function start addresses are
missing in a module. There are certain cases on Mac OS X where we
can tell that a Mach-O binary has been stripped of this essential
information, and the unwinder can end up emulating many megabytes
of instructions for a single "function" in the binary.
When a Mach-O binary is missing both an LC_FUNCTION_STARTS load
command (very unusual) and an eh_frame section, then we will assume
it has also been stripped of symbols and that instruction emulation
will not be useful on this module.
<rdar://problem/25988067>
llvm-svn: 268475
|
|
|
|
|
|
|
|
|
|
|
| |
the field_begin that starts the copy or it won't do anything.
This causes failures, but only in complex apps, I haven't found
a reduced test case for this yet.
<rdar://problem/21951798>
llvm-svn: 268467
|
|
|
|
| |
llvm-svn: 268433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As these are really testing separate issues, they should be run as separate
tests.
Reviewers: zturner, granata.enrico, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D19690
llvm-svn: 268397
|
|
|
|
|
|
|
| |
This reverts commit r268380 as it breaks windows build (I forgot to make neccesary adjustments to
ConnectionGenericFileWindows).
llvm-svn: 268384
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|