llvm-svn: 238565

llvm-svn: 238564

llvm-svn: 238563

Currently we set the field to zero, but as per the spec, we should
set numbers we read from import library files. The loader uses the
values as starting offsets for binary search when looking up imported
symbols from DLL.

llvm-svn: 238562

As a step to fix libunwind unw_step(), a new function
__gnu_unwind_frame() has been introduced to libunwind, and it is
required to use this function so that some libunwind internal data
structure can be updated properly.

llvm-svn: 238561

This commit fixes the unw_step() for ARM EHABI.  However, this commit
also changes the implementation details for ARM EHABI.

The first change is that the personality function should call
__gnu_unwind_frame() for default (or de facto) frame unwinding based on
the ARM-defined unwind opcode.  The function __gnu_unwind_frame() will
in turn calls unw_step() which actually unwinds the frame.

The second change is that the implementation _Unwind_Backtrace() should
no longer calls unw_step() to unwind the frame; since according to ARM
EHABI, the personality function should unwind the frame for us.

Special thanks to Anton for helpful suggestion on the initial version of
this patch.

llvm-svn: 238560

The complexity in here was because before r233995 variable symbols would report
the incorrect section.

llvm-svn: 238559

bug #23694

llvm-svn: 238558

llvm-svn: 238557

[Hexagon] Disassembling, printing, and emitting instructions a whole-bundle at a time which is the semantic unit for Hexagon.  Fixing tests to use the new format.  Disabling tests in the direct object emission path for a followup patch.

llvm-svn: 238556

And with that simplify the logic for inserting them in ExternalSymbolData or
LocalSymbolData.

No functionality change overall since the old code avoided the isLocal bug.

llvm-svn: 238555

llvm-svn: 238554

getCanonicalArchName can return an empty string for an architecture
that is well-formed but meaningless. Use parseArch to determine if
it's actually valid or not.

Differential Revision: http://reviews.llvm.org/D10120

llvm-svn: 238553

llvm-svn: 238552

llvm-svn: 238551

this fixes http://llvm.org/PR17424
fillAttributedTypeLoc() function is only called with AttributeLists of either
DeclarationChunk (which is used for each type in a declarator being parsed) or
DeclSpec (which captures information about declaration specifiers).
As C++11 attributes actually appertain to declarators, they are moved straight
to the declarator’s attr list in distributeFunctionTypeAttrFromDeclSpec()
function.
'Put them wherever you like' semantics is not supported for C++11 attributes
(but is allowed for GNU attributes, for example). So when we meet an attribute
while parsing the declaration, we cannot be sure if it appertains to either
DeclarationChunk or DeclSpec.

This investigation correlates with the history of changes of SemaType.cpp:
• Asserts in fillAttributedTypeLoc() were added on 3 Mar 2011 in r126986
(http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-
        20110228/039638.html);
• Distributing C++11 attrs to the declarator was added on 14 Jan 2013
in r172504 (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-
        20130114/071830.html).
Considering all written above I changed asserts in fillAttributedTypeLoc()
to nullptr checks.

This fixes PR17424 and related assertion on
[[gnu::fastcall]] void __stdcall foo();

Author: Alexey Frolov

Differential Revision: http://reviews.llvm.org/D9288

llvm-svn: 238550

Summary:
Previously, we reported inferior receiving SIGSEGV (or SIGILL, SIGFPE, SIGBUS) as an "exception"
to LLDB, presumably to match OSX behaviour. Beside the fact that we were basically lying to the
user, this was also causing problems with inferiors which handle SIGSEGV by themselves, since
LLDB was unable to reinject this signal back into the inferior.

This commit changes LLGS to report SIGSEGV as a signal. This has necessitated some changes in the
test-suite, which had previously used eStopReasonException to locate threads that crashed. Now it
uses platform-specific logic, which in the case of linux searches for eStopReasonSignaled with
signal=SIGSEGV.

I have also added the ability to set the description of StopInfoUnixSignal using the description
field of the gdb-remote packet. The linux stub uses this to display additional information about
the segfault (invalid address, address access protected, etc.).

Test Plan: All tests pass on linux and osx.

Reviewers: ovyalov, clayborg, emaste

Subscribers: emaste, lldb-commits

Differential Revision: http://reviews.llvm.org/D10057

llvm-svn: 238549

misc-static-assert and misc-assert-side-effect will handle __builtin_expect based asserts correctly.

llvm-svn: 238548

No functional change intended.

Patch by Sebastian Edman!

llvm-svn: 238547

llvm-svn: 238546

Patch by Maria Guseva!

Differential Revision: http://reviews.llvm.org/D10063

llvm-svn: 238545

Before:
  var x = {
        [a]: 1,
    b: 2
  };

After:
  var x = {
    [a]: 1,
    b: 2
  };

llvm-svn: 238544

[TableGen] Remove convertValue functions for UnOpInit, BinOpInit, and TernOpInit as they weren't able to be called.

I don't think converting the inputs to the Ops was the right behavior anyway.

llvm-svn: 238543

llvm-svn: 238542

Change ProcessEventData over to use a std::weak_ptr to a process intead of a std::shared_ptr. Anyone consuming events for a process should have the process around long enough to grab the event and anyone that holds onto an event for too long won't keep the process around.

llvm-svn: 238541

llvm-svn: 238540

MIOperands/ConstMIOperands are classes iterating over the MachineOperand
of a MachineInstr, however MachineInstr::mop_iterator does the same
thing.

I assume these two iterators exist to have a uniform interface to
iterate over the operands of a machine instruction bundle and a single
machine instruction. However in practice I find it more confusing to have 2
different iterator classes, so this patch transforms (nearly all) the
code to use mop_iterators.

The only exception being MIOperands::anlayzePhysReg() and
MIOperands::analyzeVirtReg() still needing an equivalent, I leave that
as an exercise for the next patch.

Differential Revision: http://reviews.llvm.org/D9932

This version is slightly modified from the proposed revision in that it
introduces MachineInstr::getOperandNo to avoid the extra counting
variable in the few loops that previously used MIOperands::getOperandNo.

llvm-svn: 238539

llvm-svn: 238538

llvm-svn: 238537

Fixes PR23455, where, when TableGen generates the matcher from the
AsmString, it splits "cmp${cc}ss" into tokens, and the "ss" suffix
is recognized as the SS register.

I can't think of a situation where that's a feature, not a bug, hence:
when a token is "isolated", i.e., it is followed and preceded by
separators, it shouldn't be parsed as a register.

Differential Revision: http://reviews.llvm.org/D9844

llvm-svn: 238536

Summary:
-Fix lldb test failures introduced by r238530
-This fix TestGdbRemoteAuxvSupport.py and TestLldbGdbServer.py

Test Plan:
./dotest -p TestGdbRemoteAuxvSupport.py
./dotest -p TestLldbGdbServer.py

Reviewers: clayborg, chaoren, vharron

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D10116

llvm-svn: 238535

llvm-svn: 238534

llvm-svn: 238533

Summary:
Old Android devices, for example API 16, do not have the "readlink"
command. To take care of such devices, this commit changes to use "ls -l"
instead of "readlink" to get the lldb-server exe path.

The tests fixed with this change for an Android API 16 arm device are:

TestGdbRemoteAttach
TestGdbRemoteAuxvSupport
TestGdbRemoteExpeditedRegisters
TestGdbRemoteKill
TestGdbRemoteProcessInfo
TestGdbRemoteSegFault
TestGdbRemoteThreadsInStopReply
TestGdbRemote_qThreadStopInfo

Further, all tests in TestLldbGdbServer pass (previously erroring out),
except one which times out.

Test Plan:
Run dosep.py with 8 test threads targetting Android API 16
device.

Reviewers: vharron, ovyalov

Reviewed By: ovyalov

Subscribers: tberghammer, aemerson, lldb-commits

Differential Revision: http://reviews.llvm.org/D10107

llvm-svn: 238532

Double and single rounding can produce different results.
This is the IR counterpart to r228911.

llvm-svn: 238531

qEcho:%s

where '%s' is any valid string. The response to this packet is the exact packet itself with no changes, just reply with what you received!

This will help us to recover from packets timing out much more gracefully. Currently if a packet times out, LLDB quickly will hose up the debug session. For example, if we send a "abc" packet and we expect "ABC" back in response, but the "abc" command takes longer than the current timeout value this will happen:


--> "abc"
<-- <<<error: timeout>>>

Now we want to send "def" and get "DEF" back:

--> "def"
<-- "ABC"

We got the wrong response for the "def" packet because we didn't sync up with the server to clear any current responses from previously issues commands.

The fix is to modify GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock() so that when it gets a timeout, it syncs itself up with the client by sending a "qEcho:%u" where %u is an increasing integer, one for each time we timeout. We then wait for 3 timeout periods to sync back up. So the above "abc" session would look like:

--> "abc"
<-- <<<error: timeout>>> 1 second
--> "qEcho:1"
<-- <<<error: timeout>>> 1 second
<-- <<<error: timeout>>> 1 second
<-- "abc"
<-- "qEcho:1"

The first timeout is from trying to get the response, then we know we timed out and we send the "qEcho:1" packet and wait for 3 timeout periods to get back in sync knowing that we might actually get the response for the "abc" packet in the mean time...

In this case we would actually succeed in getting the response for "abc". But lets say the remote GDB server is deadlocked and will never response, it would look like:

--> "abc"
<-- <<<error: timeout>>> 1 second
--> "qEcho:1"
<-- <<<error: timeout>>> 1 second
<-- <<<error: timeout>>> 1 second
<-- <<<error: timeout>>> 1 second

We then disconnect and say we lost connection.

We might also have a bad GDB server that just dropped the "abc" packet on the floor. We can still recover in this case and it would look like:

--> "abc"
<-- <<<error: timeout>>> 1 second
--> "qEcho:1"
<-- "qEcho:1"

Then we know our remote GDB server is still alive and well, and it just dropped the "abc" response on the floor and we can continue to debug.

<rdar://problem/21082939>

llvm-svn: 238530

llvm-svn: 238529

Summary:
-Buildbot parser depends on this line as start flag
-Will remove the dependency from buildbot parser, but it takes some time to take effect
-Will remove this line from printout after buildbot master reconfig

Reviewers: chaoren, vharron

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D10110

llvm-svn: 238527

llvm-svn: 238526

About pristine regsiters:
Pristine registers "hold a value that is useless to the current
function, but that must be preserved - they are callee saved registers
that have not been saved." This concept saves compile time as it frees
the prologue/epilogue inserter from adding every such register to every
basic blocks live-in list.

However the current code in getPristineRegs is formulated in a
complicated way: Inside the function prologue and epilogue all callee
saves are considered pristine, while in the rest of the code only the
non-saved ones are considered pristine.  This requires logic to
differentiate between prologue/epilogue and the rest and in the presence
of shrink-wrapping this even becomes complicated/expensive.  It's also
unnecessary because the prologue epilogue inserters already mark
callee-save registers that are saved/restores properly in the respective
blocks in the prologue/epilogue (see updateLiveness() in
PrologueEpilogueInserter.cpp). So only declaring non-saved/restored
callee saved registers as pristine just works.

Differential Revision: http://reviews.llvm.org/D10101

llvm-svn: 238524