The test was flaky on the android buildbot, because the 10ms test completed before we got a
chance to interrupt it. I increase the duration to 50ms to hopefully get more consistent results.
llvm-svn: 245555
Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp
Reviewers: tberghammer, ovyalov, clayborg, labath
Subscribers: lldb-commits, nitesh.jain, jaydeep
Differential: http://reviews.llvm.org/D12100
llvm-svn: 245547
On ARM there is no difference petween a pop and a load instruction so
a register can be loaded multiple times during the function. Add check
to threat the load as a restore only if it do the restore from the
same location where the register was saved.
Differential revision: http://reviews.llvm.org/D11947
llvm-svn: 245546
Summary:
There was a bug in NativeProcessLinux, where doing an instruction-level single-step over the
thread-creation syscall resulted in loss of control over the inferior. This happened because
after the inferior entered the thread-creation maintenance stop, we unconditionally performed a
PTRACE_CONT, even though the original intention was to do a PTRACE_SINGLESTEP. This is fixed by
storing the original state of the thread before the stop (stepping or running) and then
performing the appropriate action when resuming.
I also get rid of the callback in the ThreadContext structure, which stored the lambda used to
resume the thread, but which was not used consistently.
A test verifying the correctness of the new behavior is included.
Reviewers: ovyalov, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12104
llvm-svn: 245545
to the user. e.g. specified via the
plugin.process.gdb-remote.target-definition-file
setting. Currently we silently ignore the target definition if
there is a parse error.
llvm-svn: 245536
the test was failing on android because processing 30 signals involved a lot of round-trips,
which was not possible in the 0.5s default timeout. After the increase the test seems to pass
reliably.
llvm-svn: 245448
Summary:
Due to fork()/execve(), the launched inferior inherits the signal mask of its parent (lldb-server). But because lldb-server modifies its signal mask (It blocks SIGCHLD, for example), the inferior starts with some signals being initially blocked.
One consequence is that TestCallThatRestarts.ExprCommandThatRestartsTestCase (test/expression_command/call-restarts) fails because sigchld_handler() in lotta-signals.c is not called, due to the SIGCHLD signal being blocked.
To prevent the signal masking done by lldb-server from affecting the created inferior, the signal mask of the inferior is now cleared before the execve().
Patch by: Yacine Belkadi
Reviewers: ovyalov, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12138
llvm-svn: 245436
The right thing to do here would be to give the ASTConsumer to the
CompilerInstance so it can set things up for us, but we can't do that
because we don't own it. So instead just initialize it ourselves.
llvm-svn: 245397
Whether or not frames print their tid in hex or decimal is apparently
hardcoded to depend on the operating system. For now a comment was
added that this should be changed to a more sane check (for example
a setting), and the OS check is updated to do the right thing for
Windows.
llvm-svn: 245371
Name lookup doesn't work properly with Windows targets. This is
most likely due to issues with name mangling, although there is at
least one set of debug info related issues as well, since some of
the name lookup requests appear to be failing on types rather than
symbols.
Specifically, this patch XFAILS the following set of tests:
TestChar1632T.py
TestRdar12991846.py
TestConstVariables.py
TestCallCPPFunction.py
TestCallStopAndContinue.py
TestCallUserDefinedFunction.py
TestCModules.py
TestCPPThis.py
TestExprs2.py
TestOverloadedFunctions.py
TestRvalueReferences.py
And fixing the underlying issue is tracked in http://llvm.org/pr24489
llvm-svn: 245338
Summary:
in case we are logging to stdout, any log lines from the forked child can be misconstrued to be
inferior output. To avoid this, we disable all logging immediately after forking.
I also fix the implementatoion of DisableAllLogChannels, which was a no-op before this commit.
Reviewers: clayborg, ovyalov
Subscribers: dean, lldb-commits
Differential Revision: http://reviews.llvm.org/D12083
llvm-svn: 245272
TestExprDoesntBlock started failing because deadlocks behave differently with
pthread_mutex and std::mutex.
This reverts part of commit r245234.
llvm-svn: 245262
This eliminates portability issues among platforms that don't have
a pthreads implementation.
Differential Revision: http://reviews.llvm.org/D12043
Reviewed By: Greg Clayton
llvm-svn: 245234
This patch :
- Fixes offsets of all register sets for Mips.
- Adds MSA register set and FRE=1 mode support for FP register set.
- Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64.
- Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers.
Reviewers: jaydeep, clayborg, jasonmolenda, ovyalov, emaste
Subscribers: tberghammer, ovyalov, emaste, mohit.bhakkad, nitesh.jain, bhushan
Differential: http://reviews.llvm.org/D10919
llvm-svn: 245217
Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp
Reviewers: jaydeep, clayborg, jasonmolenda, ovyalov, emaste
Subscribers: tberghammer, ovyalov, emaste, mohit.bhakkad, nitesh.jain, bhushan
Differential: http://reviews.llvm.org/D10919
llvm-svn: 245216
numbers in the key name "ehframe" or "eh_frame" in addition to the deprecated
"gcc" name (e.g. from a plugin.process.gdb-remote.target-definition-file
python file).
llvm-svn: 245151
for eh_frame and stabs register numberings. This is not
complete but it's a step in the right direction. It's almost
entirely mechanical.
lldb informally uses "gcc register numbering" to mean eh_frame.
Why? Probably because there's a notorious bug with gcc on i386
darwin where the register numbers in eh_frame were incorrect.
In all other cases, eh_frame register numbering is identical to
dwarf.
lldb informally uses "gdb register numbering" to mean stabs.
There are no official definitions of stabs register numbers
for different architectures, so the implementations of gdb
and gcc are the de facto reference source.
There were some incorrect uses of these register number types
in lldb already. I fixed the ones that I saw as I made
this change.
This commit changes all references to "gcc" and "gdb" register
numbers in lldb to "eh_frame" and "stabs" to make it clear
what is actually being represented.
lldb cannot parse the stabs debug format, and given that no
one is using stabs any more, it is unlikely that it ever will.
A more comprehensive cleanup would remove the stabs register
numbers altogether - it's unnecessary cruft / complication to
all of our register structures.
In ProcessGDBRemote, when we get register definitions from
the gdb-remote stub, we expect to see "gcc:" (qRegisterInfo)
or "gcc_regnum" (qXfer:features:read: packet to get xml payload).
This patch changes ProcessGDBRemote to also accept "ehframe:"
and "ehframe_regnum" from these remotes.
I did not change GDBRemoteCommunicationServerLLGS or debugserver
to send these new packets. I don't know what kind of interoperability
constraints we might be working under. At some point in the future
we should transition to using the more descriptive names.
Throughout lldb we're still using enum names like "gcc_r0" and "gdb_r0",
for eh_frame and stabs register numberings. These should be cleaned
up eventually too.
The sources link cleanly on macosx native with xcode build. I
don't think we'll see problems on other platforms but please let
me know if I broke anyone.
llvm-svn: 245141
Pavel Labath