Commit Graph

8913 Commits

Author SHA1 Message Date
Greg Clayton 1e20f021f3 Fix some long standing issues that caused tests to be flaky.
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
2016-05-12 22:58:52 +00:00
Marianne Mailhot-Sarrasin 3fe7158174 [LLDB] Added support for PHI nodes to IR interpreter
This allows expressions such as 'i == 1 || i == 2` to be executed using the IR interpreter, instead of relying on JIT code injection (which may not be available on some platforms).

Patch by cameron314

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

llvm-svn: 269340
2016-05-12 20:00:53 +00:00
Pavel Labath 194357c509 Fix a race in ProcessGDBRemote::MonitorDebugServerProcess
Summary:
MonitorDebugServerProcess went to a lot of effort to make sure its asynchronous invocation does
not cause any mischief, but it was still not race-free. Specifically, in a quick stop-restart
sequence (like the one in TestAddressBreakpoints) the copying of the process shared pointer via
target_sp->GetProcessSP() was racing with the resetting of the pointer in DeleteCurrentProcess,
as they were both accessing the same shared_ptr object.

To avoid this, I simply pass in a weak_ptr to the process when the callback is created. Locking
this pointer is race-free as they are two separate object even though they point to the same
process instance. This also removes the need for the complicated tap-dance around retrieving the
process pointer.

Reviewers: clayborg

Subscribers: tberghammer, lldb-commits

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

llvm-svn: 269281
2016-05-12 11:10:01 +00:00
Ted Woodward 911d57840a Keep original source path and mapped path in LineEntry
Summary:
The "file" variable in a LineEntry was mapped using target.source-map, except when stepping through inlined code. This patch adds a new variable to LineEntry, "original_file", that contains the original file from the debug info. "file" will continue to (possibly) be mapped.

Some code has been changed to use "original_file". This is code dealing with symbols. Code dealing with source files will still use "file". Reviewers, please confirm that these particular changes are correct.

Tests run on Ubuntu 12.04 show no regression.

Reviewers: clayborg, jingham

Subscribers: lldb-commits

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

llvm-svn: 269250
2016-05-11 22:46:53 +00:00
Pavel Labath 998bdc5b75 Generalize child process monitoring functions
Summary:
This replaces the C-style "void *" baton of the child process monitoring functions with a more
C++-like API taking a std::function. The motivation for this was that it was very difficult to
handle the ownership of the object passed into the callback function -- each caller ended up
implementing his own way of doing it, some doing it better than others. With the new API, one can
just pass a smart pointer into the callback and all of the lifetime management will be handled
automatically.

This has enabled me to simplify the rather complicated handshake in Host::RunShellCommand. I have
left handling of MonitorDebugServerProcess (my original motivation for this change) to a separate
commit to reduce the scope of this change.

Reviewers: clayborg, zturner, emaste, krytarowski

Subscribers: lldb-commits

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

llvm-svn: 269205
2016-05-11 16:59:04 +00:00
Sagar Thakur 477eb42f85 [LLDB][MIPS] Setting appropriate ArchSpec::m_flags based on ABI
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
2016-05-11 13:08:29 +00:00
Enrico Granata c3b0a5b099 In some cases, type lookup has to deal with situations where it cannot 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
2016-05-10 18:16:33 +00:00
Pavel Labath 7189b0fdb2 Fix logging in Listener.cpp
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
2016-05-10 13:46:25 +00:00
Sean Callanan f52c40c57f Fixed multiline expressions, and removed some dead code.
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
2016-05-09 21:13:27 +00:00
Pavel Labath b8d8c62b34 Fix assertion in SymbolFilePDB
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
2016-05-09 11:07:43 +00:00
Jim Ingham 7fa7dc36fe Take the API lock in SBThread::IsValid & SBFrame::IsValid.
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
2016-05-07 00:54:56 +00:00
Jim Ingham 8bbfdcd181 Remove some lldbassert's from the packet checking code.
Greg says he doesn't need these asserts anymore and since they cause occasional test suite
crashes, out they go.

llvm-svn: 268827
2016-05-07 00:52:18 +00:00
Jim Ingham 9b8eb155d8 Fix the way the ShouldStopHere checker handles the general case of "stepping 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
2016-05-06 23:44:10 +00:00
Zachary Turner 50c58c0d01 Fix LLDB after removal of PDB_ErrorCode
llvm-svn: 268802
2016-05-06 21:35:47 +00:00
Enrico Granata 5f57b6ee0f Revert r268591
"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
2016-05-05 21:10:28 +00:00
Tamas Berghammer 21c3fdeda8 Guard AddCXXSynthetic with LLDB_DISABLE_PYTHON
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
2016-05-05 12:46:45 +00:00
Pavel Labath 0360c0f63d Bump up timeout in AdbClient
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
2016-05-05 11:25:57 +00:00
Tamas Berghammer 2ff833060c Add support for displaying Java array types on Andorid
Differential revision: http://reviews.llvm.org/D19540

llvm-svn: 268622
2016-05-05 11:18:21 +00:00
Pavel Labath c14e8ced85 Fix EOF handling in AdbClient (take 2)
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
2016-05-05 08:42:17 +00:00
Pavel Labath b9436bd493 Fix DW_AT_specification handling in DWO files
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
2016-05-05 08:21:44 +00:00
Enrico Granata 5ee5408625 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

llvm-svn: 268591
2016-05-05 01:47:44 +00:00
Enrico Granata b86dc66e75 Make the functions that fetch data from the ObjC runtime choose whether or 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
2016-05-05 01:15:57 +00:00
Adrian McCarthy 3f99810787 XFail TestLambdas.py on Windows after fixing some of the problems
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
2016-05-04 23:32:35 +00:00
Greg Clayton 4329fe4271 Don't let two threads call Debugger::Clear simultaneously.
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
2016-05-04 22:26:42 +00:00
Greg Clayton 92a20a299f Fixed a missing break and fixed spacing.
llvm-svn: 268562
2016-05-04 22:14:55 +00:00
Sean Callanan f636fc2e66 Intentionally leak the ASTSourceMap instead of destroying it when LLDB quits.
<rdar://problem/25959792>

llvm-svn: 268559
2016-05-04 21:42:55 +00:00
Zachary Turner 54fd7ff6db Update for llvm change to add pdb namespace.
r268544 moves all PDB reading code into a pdb namespace,
so LLDB needs to be updated to take this into account.

llvm-svn: 268545
2016-05-04 20:33:53 +00:00
Bryan Chan c4abaefadb Fix a SIGSEGV caused by dereferencing a pointer without a null check
llvm-svn: 268520
2016-05-04 17:24:31 +00:00
Jason Molenda 955dcf2dbc Add a way for an ObjectFile to indicate that assembly emulation
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
2016-05-04 03:09:40 +00:00
Jim Ingham c44644d6e9 You have to call setHasLoadedFieldsFromExternalStorage AFTER calling
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
2016-05-04 00:06:23 +00:00
Pavel Labath ef984e7dc0 Revert "Add a read_full_buffer argument to ConnectionFileDescriptor::Read"
This reverts commit r268380 as it breaks windows build (I forgot to make neccesary adjustments to
ConnectionGenericFileWindows).

llvm-svn: 268384
2016-05-03 14:07:41 +00:00
Pavel Labath 240760207e Add a read_full_buffer argument to ConnectionFileDescriptor::Read
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
2016-05-03 13:55:53 +00:00
Enrico Granata 0a99485341 Fix an issue where the apropos command would not print fully qualified command names for nested command objects
rdar://problem/26020072

llvm-svn: 268309
2016-05-02 21:28:40 +00:00
Sean Callanan c530ba98a9 Import block pointers from DWARF as Clang block pointers, not as structs.
Also added a data formatter that presents them as structs if you use frame
variable to look at their contents.  Now the blocks testcase works.

<rdar://problem/15984431>

llvm-svn: 268307
2016-05-02 21:15:31 +00:00
Enrico Granata 1dccd9da01 Add more debug logging to g_get_shared_cache_class_info_body
llvm-svn: 268303
2016-05-02 20:58:15 +00:00
Enrico Granata fd4e5a8801 Add an argument to ValueObject::GetSyntheticBase that allows for name customization on the generated value
llvm-svn: 268274
2016-05-02 18:13:18 +00:00
Enrico Granata 6eec8d6c6f Add support for synthetic child providers to optionally return a customized typename for display
llvm-svn: 268208
2016-05-02 00:41:24 +00:00
Kuba Brecka 5c7b363534 Improve wording and capitalization of TSan thread names.
llvm-svn: 268193
2016-05-01 11:26:06 +00:00
Kuba Brecka 2ae442b916 Add thread numbers into ASan thread names.
llvm-svn: 268192
2016-05-01 11:23:04 +00:00
Greg Clayton d49a8f9b54 Watch out for compilers that generate bad bitfield info. If the bit size of a bitfield member doesn't lie within the bit bounds of the type itself, just leave it out so we don't get clang asserting and killing our IDE when it gets unhappy with the information.
https://llvm.org/bugs/show_bug.cgi?id=27515
<rdar://problem/21082998>

llvm-svn: 268110
2016-04-29 21:26:46 +00:00
Greg Clayton 349213f941 Fix TestGetVariables.py so it works correctly. We had duplicate static values showing up as we would find static variables in the Block and also in the compile unit. We now make sure a variable hasn't been added to the list before we add it.
llvm-svn: 268101
2016-04-29 21:00:38 +00:00
Greg Clayton 909b277845 Make sure LLDB can deal with forward declarations to enums without crashing or asserting.
<rdar://problem/23776428> 

llvm-svn: 268098
2016-04-29 20:48:39 +00:00
Sean Callanan 7736a208b8 [fix] Fixed a bug where const this would cause parser errors about $__lldb_expr.
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: 268083
2016-04-29 18:09:03 +00:00
Adrian McCarthy 6cd5364556 Used llvm_unreached to quite a VC++ compiler warning.
Differential Revision: http://reviews.llvm.org/D19489

llvm-svn: 267931
2016-04-28 20:14:44 +00:00
Kuba Brecka bcdce3fd85 Provide location information (file name, line number) in TSan reports about global variables.
llvm-svn: 267894
2016-04-28 15:27:10 +00:00
Pavel Labath 35e9ea3812 Revert "Fixed a bug where const this would cause parser errors about $__lldb_expr."
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
2016-04-28 08:16:19 +00:00
Jim Ingham deb384d103 Fix an inefficiency in the handling of $__lldb_local_vars in expressions.
The code in ClangExpressionDeclMap::FindExternalVisibleDecls figures out what the token 
means, and adds the namespace to the lookup context, but since it doesn't mark it as
special in the search context, we go on to pass the name $__lldb_local_vars to the ASTSource
for further lookup.  Unless we've done our job wrong, those lookups will always fail, but
the can be costly.

So I added a bit to m_found & use that to short-circuit the lookup.

<rdar://problem/25613384>

llvm-svn: 267842
2016-04-28 02:17:02 +00:00
Jim Ingham 76bb8d6719 Add the ability to limit "source regexp" breakpoints to a particular function
within a source file.

This isn't done, I need to make the name match smarter (right now it requires an
exact match which is annoying for methods of a class in a namespace.

Also, though we use it in tests all over the place, it doesn't look like we have
a test for Source Regexp breakpoints by themselves, I'll add that in a follow-on patch.

llvm-svn: 267834
2016-04-28 01:40:57 +00:00
Sean Callanan 8bdcd52251 Fixed a bug where const this would cause parser errors about $__lldb_expr.
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
2016-04-28 01:36:21 +00:00
Kate Stone 2eabf2484f Renamed system plugin directory to address https://bugs.swift.org/browse/SR-1093
llvm-svn: 267749
2016-04-27 17:49:51 +00:00
Francis Ricci a030061c5b Use absolute module path when possible if sent in svr4 packets
Summary:
If the remote uses svr4 packets to communicate library info,
the LoadUnload tests will fail, as lldb only used the basename
for modules, causing problems when two modules have the same basename.

Using absolute path as sent by the remote will ensure that lldb
locates the module from the correct directory when there are overlapping
basenames. When debugging a remote process, LoadModuleAtAddress will still
fall back to using basename and module_search_paths, so we don't
need to worry about using absolute paths in this case.

Reviewers: ADodds, jasonmolenda, clayborg, ovyalov

Subscribers: lldb-commits, sas

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

llvm-svn: 267741
2016-04-27 17:10:15 +00:00
Jason Molenda d8f24a9c4f Committing patch from <Michael Woerister <michaelwoerister@posteo.net>
to use the default clang C/C++ expression parser when debugging
Rust programs.  Ideally there would be a rust language plugin to
support their language natively, but until then this will get simple
variable display to work.

http://reviews.llvm.org/D19545

llvm-svn: 267667
2016-04-27 04:50:51 +00:00
Jim Ingham dae50baf44 UtilityFunction::MakeFunctionCaller uses the Error to report failure,
but when there's was no process it was just returning an null pointer
and not setting the error.  I don't have a scenario where this might
go wrong, just code inspection...

llvm-svn: 267594
2016-04-26 19:46:39 +00:00
Omair Javaid e114a1711a rL267291: Architecture change to thumb on parsing arm.attributes causes regression.
Remove case handling elf arm attribute Tag_THUMB_ISA_use and setting architecture to thumb. 

Differential revision: http://reviews.llvm.org/D19520

llvm-svn: 267550
2016-04-26 11:26:00 +00:00
Omair Javaid 9a1699c0c6 Fix arm-linux-gnueabi regression due to rL267291
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
2016-04-26 01:08:59 +00:00
Jim Ingham cef461772e When building the list of variables we're going to write "using $_lldb_local_vars"
statements for, be sure not to include variables that have no locations.  We wouldn't
be able to realize them, and that will cause all expressions to fail.

llvm-svn: 267500
2016-04-26 00:29:59 +00:00
Greg Clayton 07c8c4475f Make sure that the following SymbolFileDWARF functions can handle getting a lldb::user_id_t for another SymbolFileDWARF:
CompilerDecl
SymbolFileDWARF::GetDeclForUID (lldb::user_id_t type_uid);

CompilerDeclContext
SymbolFileDWARF::GetDeclContextForUID (lldb::user_id_t type_uid)

CompilerDeclContext
SymbolFileDWARF::GetDeclContextContainingUID (lldb::user_id_t type_uid)

Type*
SymbolFileDWARF::ResolveTypeUID (lldb::user_id_t type_uid)

<rdar://problem/25592223>

llvm-svn: 267494
2016-04-25 23:39:19 +00:00
Greg Clayton a32532bfa5 Fix StackFrame::GetVariables(...) function that was broken by 261858 when lambda functions were added to Block::AppendBlockVariables(). The Stackframe::GetVariables(...) function should get all variables regardless if they are in scope.
This wasn't caught by the test suite so I added a test for it.

llvm-svn: 267478
2016-04-25 21:54:10 +00:00
Francis Ricci 55954aec70 Maintain register numbering across xml include features
Summary:
If the remote uses include features when communicating
xml register info back to lldb, the existing code would reset the
lldb register index at the beginning of each include node.
This would lead to multiple registers having the same lldb register index.
Since the lldb register numbers should be contiguous and unique,
maintain them accross the parsing of all of the xml feature nodes.

Reviewers: jingham, jasonmolenda, clayborg

Subscribers: lldb-commits, sas

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

llvm-svn: 267468
2016-04-25 21:03:55 +00:00
Francis Ricci be8cab737b Properly unload modules from target image list when using svr4 packets
Summary:
When we receive an svr4 packet from the remote, we check for new modules
and add them to the list of images in the target. However, we did not
do the same for modules which have been removed.

This was causing TestLoadUnload to fail when using ds2, which uses
svr4 packets to communicate all library info on Linux. This patch fixes
the failing test.

Reviewers: zturner, tfiala, ADodds

Subscribers: lldb-commits, sas

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

llvm-svn: 267467
2016-04-25 21:02:24 +00:00
Francis Ricci 39f1189acb Use Process Plugin register indices when communicating with remote
Summary:
eRegisterKindProcessPlugin is used to store the register
indices used by the remote, and eRegisterKindLLDB is used
to store the internal lldb register indices. However, we're currently
using the lldb indices instead of the process plugin indices
when sending p/P packets. This will break if the remote uses
non-contiguous register indices.

Reviewers: jasonmolenda, clayborg

Subscribers: lldb-commits, sas

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

llvm-svn: 267466
2016-04-25 20:59:11 +00:00
Tamas Berghammer 0237eda929 Fix ARM attribute parsing for Android after rL267291
Differential revision: http://reviews.llvm.org/D19480

llvm-svn: 267422
2016-04-25 15:51:45 +00:00
Omair Javaid cbd7f8847e Handle invalid values of PLT entry size generated by linker
Make sure we figure out correct plt entry field in case linker has generated a small value below realistic entry size like 4 bytes or below.

Differential revision: http://reviews.llvm.org/D19252

llvm-svn: 267405
2016-04-25 13:45:39 +00:00
Enrico Granata 520a422bd8 Add a --element-count option to the expression command
This option evaluates an expression and, if the result is of pointer type, treats it as if it was an array of that many elements and displays such elements

This has a couple subtle points but is mostly as straightforward as it sounds

Add a parray N <expr> alias for this new mode

Also, extend the --object-description mode to do the moral equivalent of the above but display each element in --object-description mode
Add a poarray N <expr> alias for this

llvm-svn: 267372
2016-04-25 00:52:47 +00:00
Ulrich Weigand 7793ba86d1 Fix unwind failures when PC points beyond the end of a function
RegisterContextLLDB::InitializeNonZerothFrame already has code to attempt
to detect and handle the case where the PC points beyond the end of a
function, but there are certain cases where this doesn't work correctly.

In fact, there are *two* different places where this detection is attempted,
and the failure is in fact a result of an unfortunate interaction between
those two separate attempts.

First, the ResolveSymbolContextForAddress routine is called with the
resolve_tail_call_address flag set to true.  This causes the routine
to internally accept a PC pointing beyond the end of a function, and
still resolving the PC to that function symbol.

Second, the InitializeNonZerothFrame routine itself maintains a
"decr_pc_and_recompute_addr_range" flag and, if that turns out to
be true, itself decrements the PC by one and searches again for
a symbol at that new PC value.

Both approaches correctly identify the symbol associated with the PC.
However, the problem is now that later on, we also need to find the
DWARF CFI record associated with the PC.  This is done in the
RegisterContextLLDB::GetFullUnwindPlanForFrame routine, and uses
the "m_current_offset_backed_up_one" member variable.

However, that variable only actually contains the PC "backed up by
one" if the *second* approach above was taken.  If the function was
already identified via the first approach above, that member variable
is *not* backed up by one but simply points to the original PC.
This in turn causes GetEHFrameUnwindPlan to not correctly identify
the DWARF CFI record associated with the PC.

Now, in many cases, if the first method had to back up the PC by one,
we *still* use the second method too, because of this piece of code:

    // Or if we're in the middle of the stack (and not "above" an asynchronous event like sigtramp),
    // and our "current" pc is the start of a function...
    if (m_sym_ctx_valid
        && GetNextFrame()->m_frame_type != eTrapHandlerFrame
        && GetNextFrame()->m_frame_type != eDebuggerFrame
        && addr_range.GetBaseAddress().IsValid()
        && addr_range.GetBaseAddress().GetSection() == m_current_pc.GetSection()
        && addr_range.GetBaseAddress().GetOffset() == m_current_pc.GetOffset())
    {
        decr_pc_and_recompute_addr_range = true;
    }

In many cases, when the PC is one beyond the end of the current function,
it will indeed then be exactly at the start of the next function.  But this
is not always the case, e.g. if there happens to be alignment padding
between the end of one function and the start of the next.

In those cases, we may sucessfully look up the function symbol via
ResolveSymbolContextForAddress, but *not* set decr_pc_and_recompute_addr_range,
and therefore fail to find the correct DWARF CFI record.

A very simple fix for this problem is to just never use the first method.
Call ResolveSymbolContextForAddress with resolve_tail_call_address set
to false, which will cause it to fail if the PC is beyond the end of
the current function; or else, identify the next function if the PC
is also at the start of the next function.  In either case, we will
then set the decr_pc_and_recompute_addr_range variable and back up the
PC anyway, but this time also find the correct DWARF CFI.

A related problem is that the ResolveSymbolContextForAddress sometimes
returns a "symbol" with empty name.  This turns out to be an ELF section
symbol.  Now, usually those get type eSymbolTypeInvalid.  However, there
is code in ObjectFileELF::ParseSymbols that tries to change the type of
invalid symbols to eSymbolTypeCode or eSymbolTypeData if the symbol
lies within the code or data section.

Unfortunately, this check also hits the symbol for the code section
itself, which is then marked as eSymbolTypeCode.  While the size of
the section symbol is 0 according to the ELF file, LLDB considers
this size invalid and attempts to figure out the "correct" size.
Depending on how this goes, we may end up with a symbol that overlays
part of the code section, even outside areas covered by real function
symbols.

Therefore, if we call ResolveSymbolContextForAddress with PC pointing
beyond the end of a function, we may get this bogus section symbol.
This again means InitializeNonZerothFrame thinks we have a valid PC,
but then we don't find any unwind info for it.

The fix for this problem is me to simply always leave ELF section
symbols as type eSymbolTypeInvalid.

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

llvm-svn: 267363
2016-04-24 20:49:56 +00:00
Saleem Abdulrasool d2d1504805 ObjectFile: parse EABI Attributes
This adds basic parsing of the EABI attributes section.  This section contains
additional information about the target for which the file was built.  Attempt
to infer additional architecture information from that section.

llvm-svn: 267291
2016-04-23 16:00:15 +00:00
Greg Clayton cae0855a62 DWARF layout for bitfields is wrong when the bit offset is negative.
Some older versions of clang emitted bit offsets that were negative and these bitfields would have their bitfield-ness stripped off and it would cause a clang assertion in clang assertions were enabled. I updated the bitfield C test to make sure we don't regress.

<rdar://problem/21082998> 

llvm-svn: 267248
2016-04-22 23:14:35 +00:00
Saleem Abdulrasool 6010f97ee6 Source: fix another -Wunused-variable warning
Conditionalise a variable definition which may be unused in certain compilations
due to the preprocessor.  Protect the variable accordingly.  NFC.

llvm-svn: 267247
2016-04-22 23:08:34 +00:00
Greg Clayton f443135b8c Fixed in issue with ObjectFileMachO where it would add empty sections to the section list that was used to try and cap symbols to the max address of the section in which it is contained. The empty sections would make cap the symbols and make their sizes zero. Also fixed a few other things that could cause problems in the SymbolFileDWARFDebugMap when zero sized symbols were found and used to make OSO range map entries.
<rdar://problem/25886773>

llvm-svn: 267237
2016-04-22 22:35:08 +00:00
Kuba Brecka 5b31c423a0 Renumber ThreadSanitizer-provided thread IDs to match LLDB thread numbers.
llvm-svn: 267133
2016-04-22 10:40:14 +00:00
Ryan Brown 5852c5a12f Update Go OS Plugin for newer runtimes.
Differential Revision: http://reviews.llvm.org/D19273

llvm-svn: 267048
2016-04-21 20:57:28 +00:00
Saleem Abdulrasool 358efd6557 API: fix a -Wunused-variable warning
expr_log is only conditionally used via preprocessing.  Ensure that we guard the
definition accordingly.  NFC.

llvm-svn: 267001
2016-04-21 16:56:02 +00:00
Saleem Abdulrasool 25b75a2f7d Host: fix some -Wformat-pedantic warnings
Add explicit casts for function pointer to void * for %p conversion.  NFC.

llvm-svn: 267000
2016-04-21 16:55:58 +00:00
Jim Ingham 0d6a90dfc3 Expressions can run without a process.
Code was added in ClangExpressionParser::ClangExpressionParser that was calling through
the process w/o checking that it was good.  Also, we were pretending that we could do something
reasonable if we had no target, but that's actually not true, so I check for a target at the
beginning of the constructor and don't make a compiler in that case.

<rdar://problem/25841198>

llvm-svn: 266944
2016-04-21 01:46:11 +00:00
Kate Stone 0761202612 Corrected wording of REPL not available messaging (contained a repeated word and lacked clarity.)
llvm-svn: 266941
2016-04-21 00:56:08 +00:00
Kate Stone 25d6072adc Added command prefix to new help messages to ensure that they're correctly words in REPL mode.
llvm-svn: 266940
2016-04-21 00:55:20 +00:00
Greg Clayton 0257603c2d When making an array or stuct/union/class elements, make sure the type is complete. If the type isn't complete, complete the type so that clang won't assert and kill your program. Since the DWARF assists in doing layout, it won't show the array or struct/unions/class elements correctly, but it will stop you from crashing if you have a struct/union/class that contains one of these arrays.
<rdar://problem/25057391>

llvm-svn: 266922
2016-04-20 21:47:56 +00:00
Enrico Granata 612917c784 Fix a bug where LLDB would crash if 'apropos <anything>' was used after spawning an inferior process
llvm-svn: 266911
2016-04-20 20:48:05 +00:00
Greg Clayton f258bf9017 llvm::sys::path::home_directory() relies on having "HOME" set in the environment and that might not always be set. Our FileSpec class uses this function to resolve any paths that start with "~/" on systems that support home directories as '~'. I have modified FileSpec::ResolveUsername (llvm::SmallVectorImpl<char> &path) to deal with the cases where llvm::sys::path::home_directory() returns false by digging a little further on unix systems and setting "HOME" in the environment so that subsequent calls to llvm::sys::path::home_directory() will succeed.
I also added a test to ensure we don't regress.

<rdar://problem/25342377> 

llvm-svn: 266832
2016-04-19 23:04:35 +00:00
Pavel Labath 6145366510 Revert "LLDB: Fixed two race conditions when stopping private state thread"
This reverts commit r266733 as it causes a number of failures on linux buildbots.

llvm-svn: 266736
2016-04-19 14:03:43 +00:00
Marianne Mailhot-Sarrasin 0c6d7c0a2c LLDB: Fixed two race conditions when stopping private state thread
When stopping the private state thread, there was a race condition between the time the thread exits (resetting the HostThread object) and the time a Join was attempted, especially in the case of a timeout.

The previous workaround of copying the HostThread object is not enough, since on a Reset the internal thread stuff gets nulled out regardless of which HostThread object actually has Reset called on it, resulting in an attempt to dereference a null pointer on the subsequent call to Join from the copy as well.

Additionally, there was a race between the detach (called when stopping the process) and the stop itself, causing the stop to time out because it was waiting for the private state thread to see the stop state, but it had exited immediately after entering the detached state.

Patch by cameron314

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

llvm-svn: 266733
2016-04-19 13:21:46 +00:00
Chaoren Lin 167c796232 Fix Windows build.
llvm-svn: 266702
2016-04-19 01:09:37 +00:00
Pavel Labath 7eafdced6e Attempt to fix darwin build after header refactor in llvm (r266595)
llvm-svn: 266605
2016-04-18 12:18:35 +00:00
Oleksiy Vyalov 37a09e72bc Fix cmake build after r266524.
llvm-svn: 266530
2016-04-16 16:29:17 +00:00
Pavel Labath 7ef36b5c15 Work around a linux libc bug causing a crash in TaskPool
Summary:
Doing a pthread_detach while the thread is exiting can cause crashes or other mischief, so we
make sure the thread stays around long enough. The performance impact of the added
synchronization should be minimal, as the parent thread is already holding a mutex, so I am just
making sure it holds it for a little while longer. It's possible the new thread will block on
this mutex immediately after startup, but it should be unblocked really quickly and some
blocking is unavoidable if we actually want to have this synchronization.

Reviewers: tberghammer

Subscribers: lldb-commits

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

llvm-svn: 266423
2016-04-15 10:49:07 +00:00
Ulrich Weigand 9521ad2a49 Fix usage of APInt.getRawData for big-endian systems
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
2016-04-15 09:55:52 +00:00
Ulrich Weigand 9a0fdfe009 Make Scalar::SChar return an explicit signed type
This is needed for platforms where the default "char" type is unsigned.

Originally committed as part of (now reverted) r266311.

llvm-svn: 266420
2016-04-15 09:15:47 +00:00
Ulrich Weigand fb7207ef89 Fix Scalar::MakeSigned for 128- and 256-bit types.
Obvious fix for incorrect result types of the operation.

Originally committed as part of (now reverted) r266311.

llvm-svn: 266419
2016-04-15 09:15:22 +00:00
Ulrich Weigand d8d2c5c81c Fix Scalar::SetValueFromData for 128- and 256-bit types
Obvious fix for incorrect use of GetU64 offset pointer.

Originally committed as part of (now reverted) r266311.

llvm-svn: 266418
2016-04-15 09:14:59 +00:00
Ulrich Weigand 2b6c791930 Fix ABISysV_s390x::GetArgumentValues
This routine contained a stray "return false;" making part of the code
never executed.  Also, the stack offset where to find on-stack arguments
was incorrect.

llvm-svn: 266417
2016-04-15 09:14:32 +00:00
Oleksiy Vyalov 987c8788d4 Rename out->std_out in AppleObjCRuntimeV2.cpp.
llvm-svn: 266401
2016-04-15 00:56:11 +00:00
Zachary Turner 42dff79068 Initial support for reading type information from PDBs.
This implements a PDBASTParser and corresponding logic in
SymbolFilePDB to do type lookup by name.  This is just a first
pass and leaves many aspects of type lookup unimplemented, and
just focuses on laying the framework.  With this patch, you should
be able to lookup basic types by name from a PDB.

Full class definitions are not completed yet, we will instead
just return a forward declaration of the class.

Differential Revision: http://reviews.llvm.org/D18848
Reviewed by: Greg Clayton

llvm-svn: 266392
2016-04-15 00:21:26 +00:00
Ulrich Weigand da70c17bfc Revert r266311 - Fix usage of APInt.getRawData for big-endian systems
Try to get 32-bit build bots running again.

llvm-svn: 266341
2016-04-14 17:22:18 +00:00
Ulrich Weigand bd5262629d Find .plt section in object files generated by recent ld
Code in ObjectFileELF::ParseTrampolineSymbols assumes that the sh_info
field of the .rel(a).plt section identifies the .plt section.

However, with recent GNU ld this is no longer true.  As a result of this:
https://sourceware.org/bugzilla/show_bug.cgi?id=18169
in object files generated with current linkers the sh_info field of
.rel(a).plt now points to the .got.plt section (or .got on some targets).

This causes LLDB to fail to identify any PLT stubs, causing a number of
test case failures.

This patch changes LLDB to simply always look for the .plt section by
name.  This should be safe across all linkers and targets.

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

llvm-svn: 266316
2016-04-14 14:36:29 +00:00
Ulrich Weigand 91a2ad182d Fix ARM instruction emulation tests on big-endian systems
Running the ARM instruction emulation test on a big-endian system
would fail, since the code doesn't respect endianness properly.

In EmulateInstructionARM::TestEmulation, code assumes that an
instruction opcode read in from the test file is in target byte
order, but it was in fact read in in host byte order.

More difficult to fix, the EmulationStateARM structure models
the overlapping sregs and dregs by a union in _sd_regs.  This
only works correctly if the host is a little-endian system.
I've removed the union in favor of a simple array containing
the 32 sregs, and changed any code accessing dregs to explicitly
use the correct two sregs overlaying that dreg in the proper
target order.

Also, the EmulationStateARM::ReadPseudoMemory and WritePseudoMemory
track memory as a map of uint32_t values in host byte order, and
implement 64-bit memory accessing by splitting them up into two
uint32_t ones.  However, callers expect memory contents to be
provided in the form of a byte array (in target byte order).
This means the uint32_t contents need to be byte-swapped on
BE systems, and when splitting up a 64-bit access into two 32-bit
ones, byte order has to be respected.

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

llvm-svn: 266314
2016-04-14 14:34:19 +00:00
Ulrich Weigand 0501eebda6 Miscellaneous fixes for big-endian systems
This patch fixes a bunch of issues that show up on big-endian systems:

- The gnu_libstdcpp.py script doesn't follow the way libstdc++ encodes
  bit vectors: it should identify the enclosing *word* and then access
  the appropriate bit within that word.  Instead, the script simply
  operates on bytes.  This gives the same result on little-endian
  systems, but not on big-endian.

- lldb_private::formatters::WCharSummaryProvider always assumes wchar_t
  is UTF16, even though it could also be UTF8 or UTF32.  This is mostly
  not an issue on little-endian systems, but immediately fails on BE.
  Fixed by checking the size of wchar_t like WCharStringSummaryProvider
  already does.

- ClangASTContext::GetChildCompilerTypeAtIndex uses uint32_t to access
  the virtual base offset stored in the vtable, even though the size
  of this field matches the target pointer size according to the C++
  ABI.  Again, this is mostly not visible on LE, but fails on BE.

- Process::ReadStringFromMemory uses strncmp to search for a terminator
  consisting of multiple zero bytes.  This doesn't work since strncmp
  will stop already at the first zero byte.  Use memcmp instead.

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

llvm-svn: 266313
2016-04-14 14:33:47 +00:00
Ulrich Weigand 461bd680c3 Handle bit fields on big-endian systems correctly
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
2016-04-14 14:32:57 +00:00
Ulrich Weigand ca07434234 Fix usage of APInt.getRawData for big-endian systems
The Scalar implementation and a few other places in LLDB directly
access the internal implementation of APInt values using the
getRawData method.  Unfortunately, pretty much all of these places
do not handle big-endian systems correctly.  While on little-endian
machines, the pointer returned by getRawData can simply be used as
a pointer to the integer value in its natural format, no matter
what size, this is not true on big-endian systems: getRawData
actually points to an array of type uint64_t, with the first element
of the array always containing the least-significant word of the
integer.  This means that if the bitsize of that integer is smaller
than 64, we need to add an offset to the pointer returned by
getRawData in order to access the value in its natural type, and
if the bitsize is *larger* than 64, we actually have to swap the
constituent words before we can access the value in its natural type.

This patch fixes every incorrect use of getRawData in the code base.
For the most part, this is done by simply removing uses of getRawData
in the first place, and using other APInt member functions to operate
on the integer data.

This can be done in many member functions of Scalar itself, as well
as in Symbol/Type.h and in IRInterpreter::Interpret.  For the latter,
I've had to add a Scalar::MakeUnsigned routine to parallel the existing
Scalar::MakeSigned, e.g. in order to implement an unsigned divide.

The Scalar::RawUInt, Scalar::RawULong, and Scalar::RawULongLong
were already unused and can be simply removed.  I've also removed
the Scalar::GetRawBits64 function and its few users.

The one remaining user of getRawData in Scalar.cpp is GetBytes.
I've implemented all the cases described above to correctly
implement access to the underlying integer data on big-endian
systems.  GetData now simply calls GetBytes instead of reimplementing
its contents.

Finally, two places in the clang interface code were also accessing
APInt.getRawData in order to actually construct a byte representation
of an integer.  I've changed those to make use of a Scalar instead,
to avoid having to re-implement the logic there.

The patch also adds a couple of unit tests verifying correct operation
of the GetBytes routine as well as the conversion routines.  Those tests
actually exposed more problems in the Scalar code: the SetValueFromData
routine didn't work correctly for 128- and 256-bit data types, and the
SChar routine should have an explicit "signed char" return type to work
correctly on platforms where char defaults to unsigned.

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

llvm-svn: 266311
2016-04-14 14:32:01 +00:00
Ulrich Weigand b00ef10b70 Make Scalar::GetBytes and RegisterValue::GetBytes const
Scalar::GetBytes provides a non-const access to the underlying bytes
of the scalar value, supposedly allowing for modification of those
bytes.  However, even with the current implementation, this is not
really possible.  For floating-point scalars, the pointer returned
by GetBytes refers to a temporary copy; modifications to that copy
will be simply ignored.  For integer scalars, the pointer refers
to internal memory of the APInt implementation, which isn't
supposed to be directly modifyable; GetBytes simply casts aways
the const-ness of the pointer ...

With my upcoming patch to fix Scalar::GetBytes for big-endian
systems, this problem is going to get worse, since there we need
temporary copies even for some integer scalars.  Therefore, this
patch makes Scalar::GetBytes const, fixing all those problems.

As a follow-on change, RegisterValues::GetBytes must be made const
as well.  This in turn means that the way of initializing a
RegisterValue by doing a SetType followed by writing to GetBytes
no longer works.  Instead, I've changed SetValueFromData to do
the equivalent of SetType itself, and then re-implemented
SetFromMemoryData to work on top of SetValueFromData. 

There is still a need for RegisterValue::SetType, since some
platform-specific code uses it to reinterpret the contents of
an already filled RegisterValue.  To make this usage work in
all cases (even changing from a type implemented via Scalar
to a type implemented as a byte buffer), SetType now simply
copies the old contents out, and then reloads the RegisterValue
from this data using the new type via SetValueFromData.

This in turn means that there is no remaining caller of
Scalar::SetType, so it can be removed.

The only other follow-on change was in MIPS EmulateInstruction
code, where some uses of RegisterValue::GetBytes could be made
const trivially.

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

llvm-svn: 266310
2016-04-14 14:31:08 +00:00
Ulrich Weigand 377e4213e1 Fixes for platforms that default to unsigned char
This fixes several test case failure on s390x caused by the fact that
on this platform, the default "char" type is unsigned.

- In ClangASTContext::GetBuiltinTypeForEncodingAndBitSize we should return
  an explicit *signed* char type for encoding eEncodingSint and bit size 8,
  instead of the default platform char type (which may be unsigned).
  This fix matches existing code in ClangASTContext::GetIntTypeFromBitSize,
  and fixes the TestClangASTContext.TestBuiltinTypeForEncodingAndBitSize
  unit test case.

- The test/expression_command/char/TestExprsChar.py test case is known to
  fail on platforms defaulting to unsigned char (pr23069), and just needs
  to be xfailed on s390x like on arm.

- The test/functionalities/watchpoint/watchpoint_on_vectors/main.c test
  case defines a vector of "char" and implicitly assumes to be signed.
  Use an explicit "signed char" instead.

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

llvm-svn: 266309
2016-04-14 14:30:12 +00:00
Ulrich Weigand bb00d0b6b2 Support Linux on SystemZ as platform
This patch adds support for Linux on SystemZ:
- A new ArchSpec value of eCore_s390x_generic
- A new directory Plugins/ABI/SysV-s390x providing an ABI implementation
- Register context support
- Native Linux support including watchpoint support
- ELF core file support
- Misc. support throughout the code base (e.g. breakpoint opcodes)
- Test case updates to support the platform

This should provide complete support for debugging the SystemZ platform.
Not yet supported are optional features like transaction support (zEC12)
or SIMD vector support (z13).

There is no instruction emulation, since our ABI requires that all code
provide correct DWARF CFI at all PC locations in .eh_frame to support
unwinding (i.e. -fasynchronous-unwind-tables is on by default).

The implementation follows existing platforms in a mostly straightforward
manner.  A couple of things that are different:

- We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers,
  since some registers (access register) reside at offsets in the user area
  that are multiples of 4, but the PTRACE_PEEKUSER interface only allows
  accessing aligned 8-byte blocks in the user area.  Instead, we use a s390
  specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that
  allows accessing a whole block of the user area in one go, so in effect
  allowing to treat parts of the user area as register sets.

- SystemZ hardware does not provide any means to implement read watchpoints,
  only write watchpoints.  In fact, we can only support a *single* write
  watchpoint (but this can span a range of arbitrary size).  In LLDB this
  means we support only a single watchpoint.  I've set all test cases that
  require read watchpoints (or multiple watchpoints) to expected failure
  on the platform.  [ Note that there were two test cases that install
  a read/write watchpoint even though they nowhere rely on the "read"
  property.  I've changed those to simply use plain write watchpoints. ]

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

llvm-svn: 266308
2016-04-14 14:28:34 +00:00
Ulrich Weigand 7311bb34f6 Add new ABI callback to provide fallback unwind register locations
If the UnwindPlan did not identify how to unwind the stack pointer
register, LLDB currently assumes it can determine to caller's SP
from the current frame's CFA.  This is true on most platforms
where CFA is by definition equal to the incoming SP at function
entry.

However, on the s390x target, we instead define the CFA to equal
the incoming SP plus an offset of 160 bytes.  This is because
our ABI defines that the caller has to provide a register save
area of size 160 bytes.  This area is allocated by the caller,
but is considered part of the callee's stack frame, and therefore
the CFA is defined as pointing to the top of this area.

In order to make this work on s390x, this patch introduces a new
ABI callback GetFallbackRegisterLocation that provides platform-
specific fallback register locations for unwinding.  The existing
code to handle SP unwinding as well as volatile registers is moved
into the default implementation of that ABI callback, to allow
targets where that implementation is incorrect to override it.

This patch in itself is a no-op for all existing platforms.
But it is a pre-requisite for adding s390x support.

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

llvm-svn: 266307
2016-04-14 14:25:20 +00:00
Pavel Labath a212c58db0 FileSpec: make matching separator-agnostic again
Summary:
In D18689, I removed the call to Normalize() in FileSpec::SetFile, because it no longer seemed
needed, and it resolved a quirk in the FileSpec API (spec.GetCString() returnes a path with
backslashes, but spec.GetDirectory().GetCString() has forward slashes). This turned out to be a
problem because we would consider paths with different separators as different (which led to
unresolved breakpoints for instance).

Here, I am putting back in the call to Normalize() and adding a unittest for FileSpec::Equal. I
am commenting out the GetDirectory unittests until we figure out the what is the expected
behaviour here.

Reviewers: zturner

Subscribers: lldb-commits

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

llvm-svn: 266286
2016-04-14 09:38:06 +00:00
Oleksiy Vyalov 2f5f100e72 Fix Android build after r266267
llvm-svn: 266274
2016-04-14 02:02:12 +00:00
Enrico Granata efcac211e5 Don't use auto - (try to) appease the Android g++ bot
llvm-svn: 266271
2016-04-14 01:23:01 +00:00
Enrico Granata 39c9fb7360 Augment the 'language objc class-table dump' command to take a "-v" option, which makes it print ivar and method information, as well as an optional regex argument which filters out all class names that don't match the regex
llvm-svn: 266267
2016-04-14 00:43:20 +00:00
Ed Maste 11c0b227f5 Match types in for loop to fix signedness comparison warning
llvm-svn: 266197
2016-04-13 13:32:06 +00:00
Jason Molenda 17423dd422 Update Symtab::InitAddressIndexes so that computed symbol sizes
will not exceed the bounds of their Section.  This is addressing a
problem where a file had a large space between two sections that
were not used by this module - the last symbol in the text section
had an enormous size because the distance between that and the first
symbol in the data section were used to compute the size.

http://reviews.llvm.org/D19004
<rdar://problem/25227945> 

llvm-svn: 266165
2016-04-13 04:32:49 +00:00
Greg Clayton 08f5674bfe Fixed being able to set breakpoints on destructors when we don't fully specify the demangled name. So all of the following now work:
(lldb) b ~Foo
(lldb) b Foo::~Foo
(lldb) b Bar::Foo::~Foo

Improved out C++ breakpoint locations tests as well to cover this issue.

<rdar://problem/25577252>

llvm-svn: 266139
2016-04-12 22:02:37 +00:00
Enrico Granata ade56c3ea0 Use the FormatEntity work for great good - parse summary strings before accepting them, and fail to add any strings that fail parsing
llvm-svn: 266138
2016-04-12 21:57:11 +00:00
Enrico Granata d09ae3bfc5 Cleanup the arguments for 'memory find' such that the help system reflects the real way to invoke it
llvm-svn: 266129
2016-04-12 21:26:48 +00:00
Greg Clayton 9f64fe9c14 Revert to using libdispatch to reap threads on MacOSX. Code was accidentally checked in that is now reverted.
<rdar://problem/25643874>

llvm-svn: 266118
2016-04-12 20:26:41 +00:00
Enrico Granata 15d1b4e2aa Initialize the Python script interpreter lazily (i.e. not at debugger startup)
This time it should also pass the gtests

llvm-svn: 266103
2016-04-12 18:23:18 +00:00
Jim Ingham ff7ac6a7b9 Breakpoint conditions were making result variables, which they should not do.
The result variables aren't useful, and if you have a breakpoint on a
common function you can generate a lot of these.  So I changed the
code that checks the condition to set ResultVariableIsInternal in the
EvaluateExpressionOptions that we pass to the execution.
Unfortunately, the check for this variable was done in the wrong place
(the static UserExpression::Evaluate) which is not how breakpoint
conditions execute expressions (UserExpression::Execute).  So I moved
the check to UserExpression::Execute (which Evaluate also calls) and made the
overridden method DoExecute.

llvm-svn: 266093
2016-04-12 17:17:35 +00:00
Pavel Labath ba45680758 Revert "Restore the lazy initialization of ScriptInterpreterPython, which was lost as part of the SystemLifetimeManager work"
This change breaks python unit tests.

This reverts commit 266033.

llvm-svn: 266050
2016-04-12 09:06:08 +00:00
Saleem Abdulrasool dd4799c28e Process: fix the build with certain kernel versions
The structure definitions are not provided, but we perform a sizeof operation of
them which causes a build failure.  Include `asm/ptrace.h` to get the structure
definitions.

llvm-svn: 266042
2016-04-12 05:40:51 +00:00
Enrico Granata b184bfa13b Restore the lazy initialization of ScriptInterpreterPython, which was lost as part of the SystemLifetimeManager work
llvm-svn: 266033
2016-04-12 01:08:35 +00:00
Greg Clayton a15942ff05 Fixed Variable::GetDecl() and Variable::GetDeclContext() to check the "Type *" before using it so we don't crash if a variable's type can't be realized which happens more often recently due to -gmodules.
<rdar://problem/25612626>

llvm-svn: 266023
2016-04-12 00:06:27 +00:00
Enrico Granata ea0ef6b19d Add support for resolving dynamic types of extended ObjC tagged pointers
rdar://problem/24401051

llvm-svn: 266001
2016-04-11 21:50:35 +00:00
Enrico Granata c28b3e8883 Add support for additional NSArray formatters
llvm-svn: 265979
2016-04-11 18:46:37 +00:00
Enrico Granata f22325c7aa Add a formatter for zero-sized NSData
llvm-svn: 265978
2016-04-11 18:46:26 +00:00
Bhushan D. Attarde 2cab00fb5b Remove unintentional return
llvm-svn: 265931
2016-04-11 11:19:37 +00:00
Kuba Brecka 1aad8fb772 Provide more information in ThreadSanitizer's JSON data. Move remaining TSan logic from SBThread to InstrumentationRuntime plugin.
llvm-svn: 265905
2016-04-10 18:57:38 +00:00
Enrico Granata f96fd0dd1d Remove what I believe are the last known instances of formatters that run code
llvm-svn: 265865
2016-04-08 22:49:31 +00:00
Enrico Granata f4d521836d Remove even more of the data formatters that silently run code
Fixes <rdar://problem/25629755>

llvm-svn: 265849
2016-04-08 21:24:24 +00:00
Oleksiy Vyalov bdea8dd57f Reset continue_after_async only if neither SIGINIT nor SIGSTOP received.
http://reviews.llvm.org/D18886

llvm-svn: 265843
2016-04-08 20:44:28 +00:00
Enrico Granata d72e412f68 Cleanups to command alias to refer to itself as 'command alias' and not allow to make aliases starting with a - as that isn't really supported, and is most often a mistake (trying to pass options)
llvm-svn: 265820
2016-04-08 17:56:57 +00:00
Enrico Granata 648e438a34 Add help for our regular expression commands when aliased
llvm-svn: 265819
2016-04-08 17:56:26 +00:00
Enrico Granata 979663236f Append a missing \n
llvm-svn: 265818
2016-04-08 17:55:59 +00:00
Tamas Berghammer b905e9d06f Fix-up LLDB build after rL13179
llvm-svn: 265787
2016-04-08 14:31:13 +00:00
Adrian McCarthy f9f3609704 Fix TestImport for Windows by ensuring backslashes in the directory paths are properly escaped in Python.
The Python import works by ensuring the directory of the module or package is in sys.path, and then it does a Python `import foo`.  The original code was not escaping the backslashes in the directory path, so this wasn't working.

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

llvm-svn: 265738
2016-04-07 22:52:12 +00:00
Jason Molenda 7d0027627b In GDBRemoteCommunicationClient::GetHostInfo, don't set the
os to "ios" or "macosx" if it is unspecified.  For environments
where there genuinely is no os, we don't want to errantly 
convert that to ios/macosx, e.g. bare board debugging.

Change PlatformRemoteiOS, PlatformRemoteAppleWatch, and
PlatformRemoteAppleTV to not create themselves if we have
an unspecified OS.  Same problem - these are not appropriate
platforms for bare board debugging environments.

Have Process::Attach's logging take place if either 
process or target logging is enabled.

<rdar://problem/25592378> 

llvm-svn: 265732
2016-04-07 22:00:55 +00:00
Kuba Brecka 0d66a85421 Simplify the ASan expression (follow-up for the previous commit, r265651).
llvm-svn: 265652
2016-04-07 10:07:45 +00:00
Kuba Brecka 97fe60f450 Tentative fix (add `extern "C"` declarations to expression prefix) and printing evaluation errors for AddressSanitizer (both MemoryHistoryASan.cpp and AddressSanitizerRuntime.cpp). Hopefully this will make the ASan testcases pass or at least the failure should be easier to diagnose.
llvm-svn: 265651
2016-04-07 10:02:43 +00:00
Pavel Labath ef40912a2f Revert "Reduce code duplication in ProcessGDBRemote"
In turns out this does make a functional change, in case when the inferior hits an int3 that was
not placed by the debugger. Backing out for now.

llvm-svn: 265647
2016-04-07 08:16:10 +00:00
Saleem Abdulrasool 8bd973c90b Symbol: fix build
TargetOptions is ambiguous due to a definition in LLVM and in clang.  This was
exposed by SVN r265640.  Update to fix the build against the newer revision.

llvm-svn: 265644
2016-04-07 06:51:10 +00:00
Pavel Labath 97a67572d6 Reduce code duplication in ProcessGDBRemote
Summary:
SetThreadStopInfo was checking for a breakpoint at the current PC several times. This merges the
identical code into a separate function. I've left one breakpoint check alone, as it was doing
more complicated stuff, and it did not see a way to merge that without making the interface
complicated. NFC.

Reviewers: clayborg

Subscribers: lldb-commits

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

llvm-svn: 265560
2016-04-06 16:49:13 +00:00
Pavel Labath 3ce324af6b Fix a cornercase in breakpoint reporting
Summary:
This resolves a similar problem as D16720 (which handled the case when we single-step onto a
breakpoint), but this one deals with involutary stops: when we stop a thread (e.g. because
another thread has hit a breakpont and we are doing a full stop), we can end up stopping it right
before it executes a breakpoint instruction. In this case, the stop reason will be empty, but we
will still step over the breakpoint when do the next resume, thereby missing a breakpoint hit.

I have observed this happening in TestConcurrentEvents, but I have no idea how to reproduce this
behavior more reliably.

Reviewers: clayborg

Subscribers: lldb-commits

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

llvm-svn: 265525
2016-04-06 09:10:29 +00:00
Jim Ingham bbadf2b7e5 The FixItList typedef should have been inside "class ClangDiagnostic".
llvm-svn: 265496
2016-04-06 00:25:44 +00:00
Jim Ingham b29c42f9eb If the fixed expression doesn't parse, don't tell the user about it.
llvm-svn: 265495
2016-04-06 00:25:04 +00:00
Jim Ingham 2fcb27b08c Don't write "using $_lldb_local_vars" statements for variables with
no name.  These were showing up with a recent clang, I haven't tracked
down why yet, but adding them is clearly wrong. 

llvm-svn: 265494
2016-04-06 00:24:17 +00:00
Greg Clayton a19af5812f Fix a crasher that could happen if ClangASTSource::CompleteType() found a type whose name matched, but came from a different language. We need to verify that any types we find are clang types before trying to extra a clang::QualType and then use it.
<rdar://problem/24138711>

llvm-svn: 265443
2016-04-05 19:29:05 +00:00
Stephane Sezer 6944f0eeb0 Update watchpoint help to use new -s flag
Summary: Flag updated in D233237

Reviewers: spyffe, jingham, Eugene.Zelenko

Subscribers: lldb-commits, sas

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

Change by Francis Ricci <fjricci@fb.com>

llvm-svn: 265421
2016-04-05 17:30:31 +00:00
Stephane Sezer bef0ff8c7f Print environment when dumping arch triple
Summary: Print environment from triple if it exists.

Reviewers: tfiala, clayborg

Subscribers: lldb-commits, sas

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

Change by Francis Ricci <fjricci@fb.com>

llvm-svn: 265420
2016-04-05 17:29:19 +00:00
Stephane Sezer 03f650ff14 Make sure to update Target arch if environment changed
Summary: Fixes "target list" for non-android linux platforms (ie gnu, gnueabi)

Reviewers: jasonmolenda, tfiala, clayborg, tberghammer

Subscribers: tberghammer, danalbert, lldb-commits, sas

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

Change by Francis Ricci <fjricci@fb.com>

llvm-svn: 265419
2016-04-05 17:27:52 +00:00
Stephane Sezer 3553c0e5e7 Allow gdbremote process to read modules from memory
Summary:
The logic to read modules from memory was added to LoadModuleAtAddress
in the dynamic loader, but not in process gdb remote. This means that when
the remote uses svr4 packets to give library info, libraries only present
on the remote will not be loaded.

This patch therefore involves some code duplication from LoadModuleAtAddress
in the dynamic loader, but removing this would require some amount of code
refactoring.

Reviewers: ADodds, tberghammer, tfiala, deepak2427, ted

Subscribers: tfiala, lldb-commits, sas

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

Change by Francis Ricci <fjricci@fb.com>

llvm-svn: 265418
2016-04-05 17:25:32 +00:00
Pavel Labath a933d5179e Fix a bug in linux core file handling
Summary:
There was a bug in linux core file handling, where if there was a running process with the same
process id as the id in the core file, the core file debugging would fail, as we would pull some
pieces of information (ProcessInfo structure) from the running process instead of the core file.
I fix this by routing the ProcessInfo requests through the Process class and overriding it in
ProcessElfCore to return correct data.

A (slightly convoluted) test is included.

Reviewers: clayborg, zturner

Subscribers: lldb-commits

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

llvm-svn: 265391
2016-04-05 13:07:16 +00:00
Jason Molenda 583b1a8a1b Consolidate the knowledge of what arm cores are always executing
in thumb mode into one method in ArchSpec, replace checks for
specific cores in the disassembler with calls to this.  Also call
this from the arm instruction emulation code.

The determination of whether a given ArchSpec is thumb-only is still
a bit of a hack, but at least the hack is consolidated into a single
place.  In my original version of this patch http://reviews.llvm.org/D13578
I was calling into llvm's feature arm feature tables to make this
determination, like

#include "llvm/Support/TargetRegistry.h"
#include "llvm/MC/MCSubtargetInfo.h"
#include "llvm/../../lib/Target/ARM/ARMGenRegisterInfo.inc"
#include "llvm/../../lib/Target/ARM/ARMFeatures.h"

[...]

        std::string triple (GetTriple().getTriple());
        const char *cpu = "";
        const char *features_str = "";
        const llvm::Target *curr_target = llvm::TargetRegistry::lookupTarget(triple.c_str(), Error);
        std::unique_ptr<llvm::MCSubtargetInfo> subtarget_info_up (curr_target->createMCSubtargetInfo(triple.c_str(), cpu, features_str));
        if (subtarget_info_up->getFeatureBits()[llvm::ARM::FeatureNoARM])
        {
            return true;
        }

but those tables are post-llvm-build generated and linking against them
for all of our different build system methods was a big hiccup that I
haven't had time to revisit convincingly.

I'll keep that reviews.llvm.org patch around to remind myself that I
need to take another run at linking against the necessary tables 
again in llvm.

<rdar://problem/23022803> 

llvm-svn: 265377
2016-04-05 05:01:30 +00:00
Enrico Granata 7a37df3fc3 Improve the way LLDB escapes arguments before passing them to the shell
Teach LLDB that different shells have different characters they are sensitive to, and use that knowledge to do shell-aware escaping

This helps solve a class of problems on OS X where LLDB would try to launch via sh, and run into problems if the command line being passed to the inferior contained such special markers (hint: the shell would error out and we'd fail to launch)
This makes those launch scenarios work transparently via shell expansion

Slightly improve the error message when this kind of failure occurs to at least suggest that the user try going through 'process launch' directly

Fixes rdar://problem/22749408

llvm-svn: 265357
2016-04-04 22:46:38 +00:00
Adrian McCarthy 543725c2e3 Implement `target modules dump objfile`
Differential Revision: http://reviews.llvm.org/D18464

llvm-svn: 265349
2016-04-04 21:21:49 +00:00
Adrian McCarthy 68374d1537 Set the architecture type from minidump more precisely. Differentiate i686 v i386 when possible.
llvm-svn: 265308
2016-04-04 16:41:16 +00:00
Pavel Labath 144119b86d Make FileSpec handling platform-independent
Summary:
Even though FileSpec attempted to handle both kinds of path syntaxes (posix and windows) on both
platforms, it relied on the llvm path library to do its work, whose behavior differed on
different platforms. This led to subtle differences in FileSpec behavior between platforms. This
replaces the pieces of the llvm library with our own implementations. The functions are simply
copied from llvm, with #ifdefs replaced by runtime checks for ePathSyntaxWindows.

Reviewers: zturner

Subscribers: lldb-commits

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

llvm-svn: 265299
2016-04-04 14:39:12 +00:00
Zachary Turner 9d8a97ebd1 Add some unit tests for ClangASTContext.
In doing so, two bugs were uncovered (and fixed).  The first bug
is that ClangASTContext::RemoveFastQualifiers() was broken, and
was not removing fast qualifiers (or doing anything else for that
matter).  The second bug is that UnifyAccessSpecifiers treated
AS_None asymmetrically, which is probably an edge case, but seems
like a bug nonetheless.

llvm-svn: 265200
2016-04-01 23:20:35 +00:00
Greg Clayton 58a15d5a23 Fixed an issue where if we have DWARF in an executable that has multiple languages where these languages use different type systems, you can end up trying to find the actualy definition for a forward declaration for a type, you will call:
TypeSP SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext (const DWARFDeclContext &dwarf_decl_ctx);

The problem was we might be looking for a type "Foo", and find one from another langauge. Then the DWARFASTParserClang would try to make an AST type using a CompilerType that might return an empty. 

This fix makes sure that when we create a DWARFDeclContext from a DWARFDIE that the DWARFDeclContext we set the language of the DIE. Then when we go to find matches for DWARFDeclContext, we end up with bunch of DIEs. We check each DWARFDIE that we found by asking it for its language and making sure the language is compatible with the type system that we want to use. This keeps us from using the wrong types to resolve forward declarations.

<rdar://problem/25276165>

llvm-svn: 265196
2016-04-01 22:57:22 +00:00
Enrico Granata aa05cf9980 Remove more of the code-running ObjC data formatter support
llvm-svn: 265181
2016-04-01 20:33:22 +00:00
Pavel Labath a5d09f64a1 Change a recently added assert into lldbassert
llvm-svn: 265124
2016-04-01 09:57:30 +00:00
Greg Clayton 830c81d511 Fixed an issue that could cause debugserver to return two stop reply packets ($T packets) for one \x03 interrupt. The problem was that when a \x03 byte is sent to debugserver while the process is running, and up calling:
rnb_err_t
RNBRemote::HandlePacket_stop_process (const char *p)
{
    if (!DNBProcessInterrupt(m_ctx.ProcessID()))
        HandlePacket_last_signal (NULL);
    return rnb_success;
}

In the call to DNBProcessInterrupt we did:

nub_bool_t
DNBProcessInterrupt(nub_process_t pid)
{
    MachProcessSP procSP;
    if (GetProcessSP (pid, procSP))
        return procSP->Interrupt();
    return false;
}

This would always return false. It would cause HandlePacket_stop_process to always call "HandlePacket_last_signal (NULL);" which would send an extra stop reply packet _if_ the process is stopped. On a machine with enough cores, it would call DNBProcessInterrupt(...) and then HandlePacket_last_signal(NULL) so quickly that it will never send out an extra stop reply packet. But if the machine is slow enough or doesn't have enough cores, it could cause the call to HandlePacket_last_signal() to actually succeed and send an extra stop reply packet. This would cause problems up in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() where it would get the first stop reply packet and then possibly return or execute an async packet. If it returned, then the next packet that was sent will get the second stop reply as its response. If it executes an async packet, the async packet will get the wrong response.

To fix this I did the following:
1 - in debugserver, I fixed "bool MachProcess::Interrupt()" to return true if it sends the signal so we avoid sending the stop reply twice on slower machines
2 - Added a log line to RNBRemote::HandlePacket_stop_process() to say if we ever send an extra stop reply so we will see this in the darwin console output if this does happen
3 - Added response validators to StringExtractorGDBRemote so that we can verify some responses to some packets. 
4 - Added validators to packets that often follow stop reply packets like the "m" packet for memory reads, JSON packets since "jThreadsInfo" is often sent immediately following a stop reply.
5 - Modified GDBRemoteCommunicationClient::SendPacketAndWaitForResponseNoLock() to validate responses. Any "StringExtractorGDBRemote &response" that contains a valid response verifier will verify the response and keep looking for correct responses up to 3 times. This will help us get back on track if we do get extra stop replies. If a StringExtractorGDBRemote does not have a response validator, it will accept any packet in response.
6 - In GDBRemoteCommunicationClient::SendPacketAndWaitForResponse we copy the response validator from the "response" argument over into m_async_response so that if we send the packet by interrupting the running process, we can validate the response we actually get in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse()
7 - Modified GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() to always check for an extra stop reply packet for 100ms when the process is interrupted. We were already doing this because we might interrupt a process with a \x03 packet, yet the process was in the process of stopping due to another reason. This race condition could cause an extra stop reply packet because the GDB remote protocol says if a \x03 packet is sent while the process is stopped, we should send a stop reply packet back. Now we always check for an extra stop reply packet when we manually interrupt a process.

The issue was showing up when our IDE would attempt to set a breakpoint while the process is running and this would happen:

--> \x03
<-- $T<stop reply 1>
--> z0,AAAAA,BB (set breakpoint)
<-- $T<stop reply 1> (incorrect extra stop reply packet)
--> c
<-- OK (response from z0 packet)

Now all packet traffic was off by one response. Since we now have a validator on the response for "z" packets, we do this:

--> \x03
<-- $T<stop reply 1>
--> z0,AAAAA,BB (set breakpoint)
<-- $T<stop reply 1> (Ignore this because this can't be the response to z0 packets)
<-- OK -- (we are back on track as this is a valid response to z0)
...

As time goes on we should add more packet validators.

<rdar://problem/22859505>

llvm-svn: 265086
2016-04-01 00:41:29 +00:00
Pavel Labath 63168e08bd Fix DWO breakage in r264909
Summary:
In case of Dwo, DIERef stores a compile unit offset in the main object file, and not in the dwo.
The implementation of SymbolFileDWARFDwo::GetDIE inherited from SymbolFileDWARF tried to lookup
the compilation unit in the DWO based on the main object file offset (and failed). I change the
implementation to verify the DIERef indeed references compile unit belonging to this dwo and then
lookup the die based on the die offset alone.

Includes a couple of fixes for mismatched struct/class tags.

Reviewers: tberghammer, clayborg

Subscribers: lldb-commits

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

llvm-svn: 265011
2016-03-31 13:30:04 +00:00
Enrico Granata 45d0e238d5 Add --help and --long-help options to 'command alias' such that one can now specify a help string for an alias as they are defining it
llvm-svn: 264980
2016-03-31 01:10:54 +00:00
Enrico Granata b64d3d61e3 Enhance the 'type X list' commands such that they actually alert the user if no formatters matching the constraints could be found
llvm-svn: 264957
2016-03-30 22:45:13 +00:00
Greg Clayton 2f869fe9d2 When support for DWO files was added, there were two ways to pass lldb::user_id_t out to the rest of LLDB:
1 - DWARF in .o files with debug map in executable: we would place the compile unit index in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset
2 - DWO: we would place the compile unit offset in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset

There was a mixing and matching of this and it wasn't done consistently.

Major changes include:

The DIERef constructor that takes a lldb::user_id_t now requires a SymbolFileDWARF:

DIERef(lldb::user_id_t uid, SymbolFileDWARF *dwarf)

It is needed so that it can be decoded correctly. If it is DWARF in .o files with debug map in executable, then we get the right compile unit from the SymbolFileDWARFDebugMap, otherwise, we use the compile unit offset and DIE offset for DWO or normal DWARF.

The function:

lldb::user_id_t DIERef::GetUID() const;

Now becomes

lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf) const;

Again, we need the DWARF file to encode it correctly.

This removes the need for "lldb::user_id_t SymbolFileDWARF::MakeUserID() const" and for bool SymbolFileDWARF::UserIDMatches (lldb::user_id_t uid) const". There were also many places were doing things inneficiently like:

1 - encode a dw_offset_t into a lldb::user_id_t
2 - call the public SymbolFile interface to resolve types using the lldb::user_id_t
3 - This would then decode the lldb::user_id_t into a DIERef, and then try to find that type.

There are many places that are now doing this more efficiently by storing DW_AT_type form values as DWARFFormValue objects and then making a DIERef from them and directly calling the underlying function to resolve the lldb_private::Type, lldb_private::CompilerType, lldb_private::CompilerDecl, lldb_private::CompilerDeclContext.

If there are any regressions in DWARF with DWO, we will need to fix any issues that arise since the original patch wasn't functional for the much more widely used DWARF in .o files with debug map.

<rdar://problem/25200976>

llvm-svn: 264909
2016-03-30 20:14:35 +00:00
Jim Ingham a7c5e1922d Fix header name.
llvm-svn: 264883
2016-03-30 18:14:36 +00:00
Kuba Brecka 058c302e0a Fix the ThreadSanitizer support to avoid creating empty SBThreads and to not crash when thread_id is unavailable. Plus a whitespace fix.
llvm-svn: 264854
2016-03-30 10:50:24 +00:00
Pavel Labath 1b46a72eb2 Fix warning in ThreadSanitizerRuntime
llvm-svn: 264849
2016-03-30 09:42:59 +00:00
Pavel Labath 6ce88f8d66 Fix warning in ClangExpressionParser
llvm-svn: 264847
2016-03-30 08:45:37 +00:00
Sean Callanan 3ce036b434 Don't register the addresses of private symbols from expressions.
They're not supposed to go in the symbol table, and in fact the way the JIT
is currently implemented it sometimes crashes when you try to get the
address of such a function.  So we skip them.

llvm-svn: 264821
2016-03-30 03:44:51 +00:00
Greg Clayton c44bcec6e1 LLDB top of tree SVN fails to attach to a MacOSX native process by pid only (no executable).
The problem was that the static DynamicLoaderDarwinKernel::Initialize() was recently changed to come before DynamicLoaderMacOSXDYLD::Initialize() which caused the DynamicLoaderDarwinKernel::CreateInstance(...) to be called before DynamicLoaderMacOSXDYLD::CreateInstance(...) and DynamicLoaderDarwinKernel would claim it could be the dynamic loader for a user space MacOSX process. The fix is to make DynamicLoaderDarwinKernel::CreateInstance() a bit more thourough when vetting the process so that it doesn't claim MacOSX user space processes.

<rdar://problem/25425373> 

llvm-svn: 264794
2016-03-29 22:09:24 +00:00
Jim Ingham e5ee6f04ab Figure out what the fixed expression is, and print it. Added another target setting to
quietly apply fixits for those who really trust clang's fixits.

Also, moved the retry into ClangUserExpression::Evaluate, where I can make a whole new ClangUserExpression 
to do the work.  Reusing any of the parts of a UserExpression in situ isn't supported at present.

<rdar://problem/25351938>

llvm-svn: 264793
2016-03-29 22:00:08 +00:00
Greg Clayton fee32cd9e2 When creating typedefs, don't call Type::GetName() since that might recursively call "lldb_private::Type::ResolveClangType(lldb_private::Type::ResolveStateTag)" and cause a crash. A lldb_private::Type should have a valid name if it is created without a backing CompilerType. Also provide a name that we can recognize so if we see it in a as the typename of a variable, we will know to check it out. This crash is happening quite a bit and we need to determine if this is due to incorrect debug info, or just due to some bug in LLDBD.
<rdar://problem/25192037>

llvm-svn: 264762
2016-03-29 18:22:07 +00:00
Greg Clayton 6e5c1fed08 Don't try to call getTypeSize() on a class if it isn't complete as clang will assert and kill the process.
llvm-svn: 264753
2016-03-29 17:36:38 +00:00
Pavel Labath 773c3b0d7c Move DynamicLoader plugins to SystemInitializerFull
Summary: These are not needed by lldb-server. Removing them shrinks the server by about 0.5%.

Reviewers: zturner

Subscribers: lldb-commits

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

llvm-svn: 264735
2016-03-29 15:00:26 +00:00
Pavel Labath eb0c5c8776 Fix infinite recursion in DWO file parsing
Summary:
Since r264316, clang started adding DW_AT_GNU_dwo_name attribute to dwo files (previously, this
attribute was only present in main object files), breaking pretty much every dwo test. The
problem was that we were treating the presence of said attribute as a signal that we should look
for information in an external object file, and caused us to enter an infinite loop. I fix this
by making sure we do not go looking for an external dwo file if we already *are* parsing a dwo
file.

Reviewers: tberghammer, clayborg

Subscribers: lldb-commits

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

llvm-svn: 264729
2016-03-29 13:42:02 +00:00
Zachary Turner d133f6acf1 Move some functions from DWARFASTParserClang to ClangASTImporter.
This allows these functions to be re-used by a forthcoming
PDBASTParser.  The functions in question are CanCompleteType,
CompleteType, and CanImport.  Conceptually, these functions belong
on ClangASTImporter anyway, and previously they were just ping
ponging around through a few levels of indirection to end up there
as well, so this patch actually makes the code somewhat simpler.

A few methods were moved to a new file called ClangUtil, so that
they can be shared between ClangASTImporter and ClangASTContext
without creating a circular dependency between those two cpp
files.

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

llvm-svn: 264685
2016-03-28 22:53:41 +00:00
Sean Callanan 863fab69a2 Expose top-level Clang expressions via the command line and the API.
Top-level Clang expressions are expressions that act as new translation units,
and define their own symbols.  They do not have function wrappers like regular
expressions do, and declarations are persistent regardless of use of the dollar
sign in identifiers.  Names defined by these are given priority over all other
symbol lookups.

This patch adds a new expression option, '-p' or '--top-level,' which controls
whether the expression is treated this way.  It also adds a flag controlling 
this to SBExpressionOptions so that this API is usable externally.  It also adds
a test that validates that this works.  (The test requires a fix to the Clang
AST importer which I will be committing shortly.)

<rdar://problem/22864976>

llvm-svn: 264662
2016-03-28 21:20:05 +00:00
Sean Callanan 2ff00003f1 Don't try to actually run code when the expression is top-level.
llvm-svn: 264660
2016-03-28 21:10:36 +00:00
Sean Callanan 38167d2536 Removed an override of LookupSymbol that mistakenly disabled it for Clang.
llvm-svn: 264659
2016-03-28 21:07:53 +00:00
Sean Callanan d0234c4593 When we import the definition for a Tagdecl, propagate its completeness too.
The ASTImporter completes the full definiton for a TagDecl in several places,
including the type-deport logic.  When this happens, we should also propagate
the bit that says that this is a complete definition.  This makes (for example)
lambdas callable.

<rdar://problem/22864976>

llvm-svn: 264485
2016-03-26 00:37:55 +00:00
Sean Callanan 47cca78efa Record all translation units with more than one function in them (e.g., blocks).
Blocks and lambdas have their implementation functions stored in the IR for an
expression.  If we put the block/lambda into a result variable it needs to stay
around.  As a heuristic, remember any execution unit that has more than one
function in it.

<rdar://problem/22864976>

llvm-svn: 264483
2016-03-26 00:30:40 +00:00
Sean Callanan ed963704f5 Removed LoggingDiagnosticConsumer, an unused class.
llvm-svn: 264478
2016-03-25 23:51:25 +00:00
Stephane Sezer 65fd8f4345 Fix FILE * leak in Python API
Summary:
This fixes a leak introduced by some of these changes:
r257644
r250530
r250525

The changes made in these patches result in leaking the FILE* passed
to SetImmediateOutputFile. GetStream() will dup() the fd held by the
python caller and create a new FILE*. It will then pass this FILE*
to SetImmediateOutputFile, which always uses the flag
transfer_ownership=false when it creates a File from the FILE*.

Since transfer_ownership is false, the lldb File destructor will not
close the underlying FILE*. Because this FILE* came from a dup-ed fd,
it will also not be closed when the python caller closes its file.

Leaking the FILE* causes issues if the same file is used multiple times
by different python callers during the same lldb run, even if these
callers open and close the python file properly, as you can end up
with issues due to multiple buffered writes to the same file.

Reviewers: granata.enrico, zturner, clayborg

Subscribers: zturner, lldb-commits, sas

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

Change by Francis Ricci <fjricci@fb.com>

llvm-svn: 264476
2016-03-25 23:40:32 +00:00
Enrico Granata 221cfdd7b1 Add a 'language cplusplus demangle' command. This can be useful to provide a low-friction reproduction for issues with the LLDB demangling of C++ symbols
llvm-svn: 264474
2016-03-25 23:14:24 +00:00
Enrico Granata 3c110dd6b4 Fix an issue with nested aliases where the help system wouldn't correctly track the fact that an alias is an alias to a dash-dash alias
(and I hope I typed the word 'alias' enough times in this commit message :-)

llvm-svn: 264468
2016-03-25 21:59:06 +00:00
Lang Hames 09ff326ca2 Fix now-ambiguous references to Error.
llvm-svn: 264449
2016-03-25 19:27:24 +00:00
Jason Molenda aef8452729 Add the same host logging that I added to PlatformRemoteiOS a few
months back to PlatformRemoteAppleTV and PlatformRemoteAppleWatch
to help understand what's happening when lldb can't find binaries
that it should be finding.

llvm-svn: 264380
2016-03-25 02:17:27 +00:00
Jim Ingham a1e541bf9f Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. "." for "->".)
This feature is controlled by an expression command option, a target property and the
SBExpressionOptions setting.  FixIt's are only applied to UserExpressions, not UtilityFunctions,
those you have to get right when you make them.

This is just a first stage.  At present the fixits are applied silently.  The next step
is to tell the user about the applied fixit.

<rdar://problem/25351938>

llvm-svn: 264379
2016-03-25 01:57:14 +00:00
Greg Clayton c9a078a4b1 Ignore global constructor warning in clang.
llvm-svn: 264361
2016-03-24 23:50:03 +00:00
Enrico Granata 701338a75f Make it possible for language plugins to provide additional custom help for 'type lookup'
llvm-svn: 264356
2016-03-24 23:06:42 +00:00
Stephane Sezer c5273d929f Make File option flags consistent for Python API
Summary:
Fixes SBCommandReturnObject::SetImmediateOutputFile() and
SBCommandReturnObject::SetImmediateOutputFile() for files opened
with "a" or "a+" by resolving inconsistencies between File and
our Python parsing of file objects.

Reviewers: granata.enrico, Eugene.Zelenko, jingham, clayborg

Subscribers: lldb-commits, sas

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

Change by Francis Ricci <fjricci@fb.com>

llvm-svn: 264351
2016-03-24 22:22:20 +00:00
Greg Clayton 1cf2aa8257 Get rid of a global constructor and also make this code safe to use after the global destructor chain has been run on the main thread.
llvm-svn: 264348
2016-03-24 21:49:22 +00:00
Greg Clayton 1e05c3bc28 Get rid of two global constructors by making things static variables in the only function that uses these variables.
llvm-svn: 264347
2016-03-24 21:48:10 +00:00
Greg Clayton 8e1232af42 Get rid of a global constructor that was causing a warning on MacOSX and make the Timer safe to use after the main threads global destructor chain is called.
llvm-svn: 264346
2016-03-24 21:46:47 +00:00
Enrico Granata 3cf9ff12c5 Make 'type lookup' print an error message instead of complete radio silence when it can't find a type matching user input
It would be fun to make it provide suggestions (e.g. 'can't find NString, did you mean NSString instead?'), but this worries me a little bit on the account of just how thorough of a type system scan it would have to do

llvm-svn: 264343
2016-03-24 21:32:39 +00:00
Ted Woodward fab31220fe Fix for missing prompt on Windows
Summary: On Windows (and possibly other hosts with LLDB_DISABLE_LIBEDIT defined), the (lldb) prompt won't print after async output, like from a breakpoint hit or a step. This patch forces the prompt to be printed out after async output.

Reviewers: zturner, clayborg

Subscribers: amccarth, lldb-commits

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

llvm-svn: 264332
2016-03-24 20:35:03 +00:00
Siva Chandra 02f593f0b8 [JITLoaderGDB] Read jit entry struct manually.
Summary:
Though r264012 was fancy enough to make reading the jit entry struct
work with templates, the packing and alignment attributes do not work on
Windows. So, this change makes it plain and simple with manual reading
of the jit entry struct.

Reviewers: clayborg

Subscribers: lldb-commits

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

llvm-svn: 264217
2016-03-23 23:27:23 +00:00
Stephane Sezer 8e38c66645 Implement ObjectFilePECOFF::GetEntryPointAddress.
Reviewers: zturner, clayborg

Subscribers: lldb-commits

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

llvm-svn: 264173
2016-03-23 18:00:13 +00:00
Kuba Brecka 6a83143650 Add ThreadSanitizer debugging support.
This patch adds ThreadSanitizer support into LLDB:
- Adding a new InstrumentationRuntime plugin, ThreadSanitizerRuntime, in the same way ASan is implemented.
- A breakpoint stops in `__tsan_on_report`, then we extract all sorts of information by evaluating an expression. We then populate this into StopReasonExtendedInfo.
- SBThread gets a new API, SBThread::GetStopReasonExtendedBacktraces(), which returns TSan’s backtraces in the form of regular SBThreads. Non-TSan stop reasons return an empty collection.
- Added some test cases.

Reviewed by Greg Clayton.

llvm-svn: 264162
2016-03-23 15:36:22 +00:00
Enrico Granata d033e1cef5 Change 'apropos' such that it doesn't look into the "long help/syntax" strings for commands
This solves issues such as 'apropos foo' returning valid matches just because syntax examples happen to use 'foo' as a placeholder token

Fixes rdar://9043025

llvm-svn: 264123
2016-03-23 01:21:55 +00:00
Enrico Granata bfb75e9bbc Make it so that a command alias can actually remove the help/long help from its parent command by setting itself to an empty help string
llvm-svn: 264108
2016-03-22 22:12:59 +00:00
Enrico Granata 660764a060 Fix a bug caused by my alias refactoring where, if an alias was defined in terms of another alias, trying to run the nested command would actually cause a crash in the command interpreter
llvm-svn: 264096
2016-03-22 21:07:54 +00:00
Sean Callanan 00294b34a3 Backend support for top-level Clang epxressions
This patch adds a new ExecutionPolicy, eExecutionPolicyTopLevel, which
tells the expression parser that the expression should be JITted as top
level code but nothing (except static initializers) should be run.  I
have modified the Clang expression parser to recognize this execution
policy.  On top of the existing patches that support storing IR and
maintaining a map of arbitrary Decls, this is mainly just patching up a
few places in the expression parser.

I intend to submit a patch for review that exposes this functionality
through the "expression" command and through the SB API.  That patch
also includes a testcase for all of this.

<rdar://problem/22864976>

llvm-svn: 264095
2016-03-22 21:05:51 +00:00
Zachary Turner 190fadcdb2 Unicode support on Win32.
Win32 API calls that are Unicode aware require wide character
strings, but LLDB uses UTF8 everywhere.  This patch does conversions
wherever necessary when passing strings into and out of Win32 API
calls.

Patch by Cameron
Differential Revision: http://reviews.llvm.org/D17107
Reviewed By: zturner, amccarth

llvm-svn: 264074
2016-03-22 17:58:09 +00:00
Mohit K. Bhakkad 19d806792a [LLDB]{MIPS] Fix TestPlatformProcessConnect.py
Patch by Nitesh Jain

Reviewers: clayborg, labath.
Subscribers: jaydeep, bhushan, mohit.bhakkad, sagar, lldb-commits.
Differential Revision: http://reviews.llvm.org/D18082

llvm-svn: 264030
2016-03-22 08:08:02 +00:00
Siva Chandra f027e130d8 [JITLoaderGDB] Pack the jit entry struct according to the target arch.
Reviewers: clayborg

Subscribers: tberghammer, dsrbecky, lldb-commits

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

llvm-svn: 264012
2016-03-22 00:35:31 +00:00
Sean Callanan bd4dc69308 Collect IRExecutionUnits as part of persistent expression state.
IRExecutionUnits contain code and data that persistent declarations can
depend on.  In order to keep them alive and provide for lookup of these
symbols, we now allow any PersistentExpressionState to keep a list of
execution units.  Then, when doing symbol lookup on behalf of an 
expression, any IRExecutionUnit can consult the persistent expression
states on a particular Target to find the appropriate symbol.

<rdar://problem/22864976>

llvm-svn: 263995
2016-03-21 22:23:38 +00:00
Jim Ingham 6896b35585 Compilation can end up calling functions (e.g. to resolve indirect functions) so I added
a way for compilation to take a "thread to use for compilation".  If it isn't set then the
compilation will use the currently selected thread.  This should help keep function execution
to the one thread intended.

llvm-svn: 263972
2016-03-21 19:21:13 +00:00
Jim Ingham d23be3d30d Use Enrico's new CommandAlias to give better help to the "sif" command.
llvm-svn: 263865
2016-03-19 00:53:20 +00:00
Sean Callanan b3a36df39e Handle any persistent Decl in the Clang expression parser, not just types.
Persistent decls have traditionally only been types.  However, we want to
be able to persist more things, like functions and global variables.  This
changes some of the nomenclature and the lookup rules to make this possible.

<rdar://problem/22864976>

llvm-svn: 263864
2016-03-19 00:51:43 +00:00
Sean Callanan 579e70c9b0 Add a DiagnosticManager replace error streams in the expression parser.
We want to do a better job presenting errors that occur when evaluating
expressions. Key to this effort is getting away from a model where all
errors are spat out onto a stream where the client has to take or leave
all of them.

To this end, this patch adds a new class, DiagnosticManager, which
contains errors produced by the compiler or by LLDB as an expression
is created. The DiagnosticManager can dump itself to a log as well as
to a string. Clients will (in the future) be able to filter out the
errors they're interested in by ID or present subsets of these errors
to the user.

This patch is not intended to change the *users* of errors - only to
thread DiagnosticManagers to all the places where streams are used. I
also attempt to standardize our use of errors a bit, removing trailing
newlines and making clients omit 'error:', 'warning:' etc. and instead
pass the Severity flag.

The patch is testsuite-neutral, with modifications to one part of the
MI tests because it relied on "error: error:" being erroneously
printed. This patch fixes the MI variable handling and the testcase.

<rdar://problem/22864976>

llvm-svn: 263859
2016-03-19 00:03:59 +00:00
Greg Clayton 6a41dae468 Fixed an case fall through that wasn't meant to happen. Caught by clang's unannotated case fall through warning.
llvm-svn: 263826
2016-03-18 20:36:30 +00:00
Greg Clayton 31460392c1 Fixed a bug where DW_AT_start_scope would fall through to DW_AT_artificial in SymbolFileDWARF::ParseVariableDIE(). This was caught by the clang warning that catches unannotated case fall throughs.
llvm-svn: 263824
2016-03-18 20:33:49 +00:00
Stephane Sezer f81049184a Fix deadlock due to thread list locking in 'bt all' with obj-c
Summary:
The gdb-remote async thread cannot modify thread state while the main thread
holds a lock on the state. Don't use locking thread iteration for bt all.

Specifically, the deadlock manifests when lldb attempts to JIT code to
symbolicate objective c while backtracing. As part of this code path,
SetPrivateState() is called on an async thread. This async thread will
block waiting for the thread_list lock held by the main thread in
CommandObjectIterateOverThreads. The main thread will also block on the
async thread during DoResume (although with a timeout), leading to a
deadlock. Due to the timeout, the deadlock is not immediately apparent,
but the inferior will be left in an invalid state after the bt all completes,
and objective-c symbols will not be successfully resolved in the backtrace.

Reviewers: andrew.w.kaylor, jingham, clayborg

Subscribers: sas, lldb-commits

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

Change by Francis Ricci <fjricci@fb.com>

llvm-svn: 263735
2016-03-17 18:52:41 +00:00
Pavel Labath 4d4e5512b5 Fix null pointer "dereference" in DomainSocket
offsetof is the official way to get the offset of a field in a structure.

llvm-svn: 263637
2016-03-16 14:03:20 +00:00
Pavel Labath 39aab4d606 Fix thread/process ID reading from linux core files
Summary:
This also adds a basic smoke test for linux core file reading. I'm checking in the core files as
well, so that the tests can run on all platforms. With some tricks I was able to produce
reasonably-sized core files (~40K).

This fixes the first part of pr26322.

Reviewers: zturner

Subscribers: lldb-commits

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

llvm-svn: 263628
2016-03-16 09:19:57 +00:00
Pavel Labath a7760cb550 Move OperatingSystem plugins to SystemInitializerFull
Summary: These are not needed in lldb-server. Removing them shrinks the server size by about 1.5%.

Reviewers: zturner

Subscribers: lldb-commits

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

llvm-svn: 263625
2016-03-16 08:48:56 +00:00
Enrico Granata ab2b0cb992 On some platforms, the compiler is allowed to assume that BOOL == bool. On others, BOOL == signed char.
This can cause differences in which bit patterns end up meaning YES or NO. In general, however, 0 == NO and 1 == YES.

To keep it simple, LLDB will now show "YES" and "NO" only for 1 and 0 respectively, and format other values as the plain numeric value instead.

Fixes rdar://24809994

llvm-svn: 263604
2016-03-15 23:38:04 +00:00
Enrico Granata 35f94bb72c Make it so that the data formatter for NSError can see through a variable of type NSError**. Fixes rdar://25060684
llvm-svn: 263603
2016-03-15 23:20:10 +00:00
Greg Clayton 2591fe1985 Only try to load the OS plug-in after a shared library load if we don't already have one.
<rdar://problem/24162686>

llvm-svn: 263602
2016-03-15 22:44:07 +00:00
Greg Clayton 0a5f805410 Fix ClangASTContext::GetFunctionArgumentAtIndex() to not water down the type to the canonical type before handing the type out for the function type.
llvm-svn: 263601
2016-03-15 22:43:26 +00:00
Enrico Granata 592afe73ad Improve the 'type lookup' command such that it guesses to use the current's frame language as the one to start searching from.
llvm-svn: 263592
2016-03-15 21:50:51 +00:00
Jim Ingham 9d9b46bf74 Remove unnecessary <limits> includes.
llvm-svn: 263588
2016-03-15 21:11:02 +00:00
Ewan Crawford 27fc7a7b47 Fix expression evaluation for resolving anonymous aggregrate types with a typedefed name
This fixes a recently reported a bug(https://llvm.org/bugs/show_bug.cgi?id=26790) relating to the clang expression evaluator no longer being able to resolve calls to
functions with arguments to typedefed anonymous structs, unions, or enums after a cleanup to the expression parsing code in r260768

This fixes the issue by attaching the tagged name to the original clang::TagDecl object when generating the typedef in lldb::ClangAstContext::CreateTypeDef.

This also fixes the issue for anonymous typedefs for non-struct types (unions and enums) where we have a tag name.


Author: Luke Drummond <luke.drummond@codeplay.com>
Differential Revision: http://reviews.llvm.org/D18099

llvm-svn: 263544
2016-03-15 09:50:16 +00:00
Enrico Granata ee88b61500 Workaround the fact that "b" is now a separate command object from "_regexp-break", and thus "help b" doesn't show the possible syntaxes
It would be nice to have a longer-term plan for how to handle help for regular expression commands, since their syntax is highly irregular. I can see a few options (*), but for now this is a reasonable stop-gag measure for the most blatant regression.

(*) the simplest is, of course, to detect a regex command and inherit the syntax for any aliases thereof; it would be nice if this also didn't show the underlying regex command name when the alias is used

llvm-svn: 263523
2016-03-15 01:57:10 +00:00
Enrico Granata dbe8d4f339 Improve the way we decide whether an alias is a dashdash alias
llvm-svn: 263519
2016-03-15 01:42:34 +00:00
Enrico Granata 4ebb8a4761 This was printing arguments twice in dash-dash aliases; don't do that
llvm-svn: 263517
2016-03-15 01:17:32 +00:00
Enrico Granata bef55ac8f5 Lots of progress on the CommandAlias refactoring
This cleans things up such CommandAlias essentially can work as its own object; the aliases still live in a separate map, but are now just full-fledged CommandObjectSPs
This patch also cleans up help generation for aliases, allows aliases to vend their own help, and adds a tweak such that "dash-dash aliases", such as po, don't show the list of options for their underlying command, since those can't be provided anyway

I plan to fix up a few more things here, and then add a test case and proclaim victory

llvm-svn: 263499
2016-03-14 22:17:04 +00:00
Ed Maste 7d1eb1de74 Shuffle an #undef to avoid a warning on FreeBSD
On FreeBSD _LIBCPP_EXTERN_TEMPLATE is being defined from something
included by lldb/lldb-private.h. Undefine it after the #include to avoid
the redefinition warning.

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

llvm-svn: 263486
2016-03-14 20:39:08 +00:00
Enrico Granata 3e271af415 More of the alias refactoring work! CommandAlias is now a CommandObject
llvm-svn: 263468
2016-03-14 19:00:21 +00:00
Ed Maste 81955f8048 Allow any build-id length between 4 and 20 bytes inclusive
Build-id support is being added to lld and by default it may produce a
64-bit build-id.

Prior to this change lldb would reject such a build-id. However, it then
falls back to a 4-byte crc32, which is a poorer quality identifier.

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

llvm-svn: 263432
2016-03-14 14:06:00 +00:00
Jim Ingham 190636bcc1 Let's not convert from UINT32_MAX to the std::numeric_limits version.
llvm-svn: 263333
2016-03-12 03:33:36 +00:00
Jim Ingham 8d94ba0fb1 This change introduces a "ExpressionExecutionThread" to the ThreadList.
Turns out that most of the code that runs expressions (e.g. the ObjC runtime grubber) on
behalf of the expression parser was using the currently selected thread.  But sometimes,
e.g. when we are evaluating breakpoint conditions/commands, we don't select the thread
we're running on, we instead set the context for the interpreter, and explicitly pass
that to other callers.  That wasn't getting communicated to these utility expressions, so
they would run on some other thread instead, and that could cause a variety of subtle and
hard to reproduce problems.  

I also went through the commands and cleaned up the use of GetSelectedThread.  All those
uses should have been trying the thread in the m_exe_ctx belonging to the command object
first.  It would actually have been pretty hard to get misbehavior in these cases, but for
correctness sake it is good to make this usage consistent.

<rdar://problem/24978569>

llvm-svn: 263326
2016-03-12 02:45:34 +00:00
Eugene Zelenko 0e28a19683 Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes.
llvm-svn: 263312
2016-03-12 00:31:13 +00:00
Eugene Zelenko 8918372dd3 Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes.
llvm-svn: 263300
2016-03-11 21:55:47 +00:00
Eugene Zelenko c5dac77ad8 Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes.
llvm-svn: 263289
2016-03-11 20:20:38 +00:00
Marianne Mailhot-Sarrasin 7a4eed280a Fixed MemoryCache L1 cache flush
Use the same method to find the cache line as in Read().

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

llvm-svn: 263233
2016-03-11 13:50:10 +00:00
Pavel Labath cc0e87cdae Fix a couple of cornercases in FileSpec + tests
Summary:
This fixes a couple of corner cases in FileSpec, related to AppendPathComponent and
handling of root directory (/) file spec. I add a bunch of unit tests for the new behavior.

Summary of changes:
FileSpec("/bar").GetCString(): before "//bar", after "/bar".
FileSpec("/").CopyByAppendingPathComponent("bar").GetCString(): before "//bar", after "/bar".
FileSpec("C:", ePathSyntaxWindows).CopyByAppendingPathComponent("bar").GetCString(): before "C:/bar", after "C:\bar".

Reviewers: clayborg, zturner

Subscribers: lldb-commits

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

llvm-svn: 263207
2016-03-11 08:44:44 +00:00
Eugene Zelenko a74f37a599 Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes.
llvm-svn: 263174
2016-03-10 23:57:12 +00:00
Marianne Mailhot-Sarrasin 82a827de3b Fixed ValueObject::GetExpressionPath() for paths including anonymous struct/union
When the parent of an expression is anonymous, skip adding '.' or '->' before the expression name.

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

llvm-svn: 263166
2016-03-10 22:10:59 +00:00
Greg Clayton a31baf081b Fixed the python interpreter so that it correctly inherits the top IOHandler's files instead of always using stdin/out/err.
Removed lldb_private::File::Duplicate() and the copy constructor and the assignment operator that used to duplicate the file handles and made them private so no one uses them. Previously the lldb_private::File::Duplicate() function duplicated files that used file descriptors, (int) but not file streams (FILE *), so the lldb_private::File::Duplicate() function only worked some of the time. No one else excep thee ScriptInterpreterPython was using these functions, so that aren't needed nor desired. Previously every time you would drop into the python interpreter we would duplicate files, and now we avoid this file churn.

<rdar://problem/24877720>

llvm-svn: 263161
2016-03-10 20:49:32 +00:00
Aidan Dodds 67dc3e1575 [Renderscript] Add stack argument reading code for Mipsel 3
Fix a problem raised with the previous patches being applied in the wrong order.

Committed on behalf of: Dean De Leo <dean@codeplay.com>

llvm-svn: 263134
2016-03-10 17:50:01 +00:00
Aidan Dodds 6dd4b57987 [Renderscript] Add stack argument reading code for Mipsel 2
This commit implements the reading of stack spilled function arguments for little endian MIPS targets.

Committed on behalf of: Dean De Leo <dean@codeplay.com>

llvm-svn: 263131
2016-03-10 17:37:02 +00:00
Aidan Dodds 17e07c0ab4 [Renderscript] Add stack argument reading code for Mipsel
This commit implements the reading of stack spilled function arguments for little endian MIPS targets.

Committed on behalf of: Dean De Leo <dean@codeplay.com>

llvm-svn: 263130
2016-03-10 17:27:41 +00:00
Aidan Dodds 8433fdbedf [Renderscript] Explicitly set the language to evaluate allocations
Currently it is not specified, and since allocations are usually
requested once we hit a renderscript breakpoint, the language will be
inferred being as renderscript by the ExpressionParser.
Actually allocations attempt to invoke functions part of the RS runtime,
written in C/C++, so evaluating the calls in RenderScript could be
misleading.

In particular, in MIPS, the ABI between C/C++ (mips o32) and
renderscript (arm) might introduce subtle bugs when evaluating such
expressions.

This change explicitly sets the language used to evaluate the allocations
as C++.

Committed on behalf of: Dean De Leo <dean@codeplay.com>

llvm-svn: 263129
2016-03-10 17:23:33 +00:00
Ewan Crawford 7648dd375f Revert "Track expression language from one place in ClangExpressionParser"
r263099 seems to have broken some OSX tests

llvm-svn: 263107
2016-03-10 12:38:55 +00:00
Ewan Crawford 6dc9db5244 Track expression language from one place in ClangExpressionParser
The current expression language is currently tracked in a few places within the ClangExpressionParser constructor. 
This patch adds a private lldb::LanguageType attribute to the ClangExpressionParser class and tracks the expression language from that one place.

Author: Luke Drummond <luke.drummond@codeplay.com>
Differential Revision: http://reviews.llvm.org/D17719

llvm-svn: 263099
2016-03-10 10:31:08 +00:00
Siva Chandra aaae5f87af [DWARFASTParserClang] Start with member offset of 0 for members of union types.
Summary:
GCC does not emit DW_AT_data_member_location for members of a union.
Starting with a 0 value for member locations helps is reading union types
in such cases.

Reviewers: clayborg

Subscribers: ldrumm, lldb-commits

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

llvm-svn: 263085
2016-03-10 01:15:17 +00:00
Enrico Granata 391075c38e Certain hardware architectures have registers of 256 bits in size
This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers)

llvm-svn: 263079
2016-03-10 00:14:29 +00:00
Zachary Turner 7e8c7bea79 Fix SymbolFilePDB for discontiguous functions.
Previously line table parsing code assumed that the only gaps would
occur at the end of functions.  In practice this isn't true, so this
patch makes the line table parsing more robust in the face of
functions with non-contiguous byte arrangements.

llvm-svn: 263078
2016-03-10 00:06:26 +00:00
Ted Woodward eee554d86e Fix "ninja check-lldb" crash in IRExecutionUnit.cpp
Summary:
From Adrian McCarthy:

"Running ninja check-lldb now has one crash in a Python process, due to deferencing a null pointer in IRExecutionUnit.cpp:  candidate_sc.symbol is null, which leads to a call with a null this pointer."

Reviewers: zturner, spyffe, amccarth

Subscribers: ted, jingham, lldb-commits

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

llvm-svn: 263066
2016-03-09 22:05:17 +00:00
Jim Ingham 2411167fb5 Add an "offset" option to "break set -n" and "break set -f -l".
That way you can set offset breakpoints that will move as the function they are 
contained in moves (which address breakpoints can't do...)

I don't align the new address to instruction boundaries yet, so you have to get
this right yourself for now.

<rdar://problem/13365575>

llvm-svn: 263049
2016-03-09 18:59:13 +00:00
Enrico Granata 4643c01284 Last round of preliminary cleanup in my refactoring of aliases.
The next step is to actually turn CommandAlias into a full-blown CommandObject citizen.

This is tricky given the current architecture of the CommandInterpreter but I think I have found a reasonable path forward.
The current plan is to make class CommandAlias : public CommandObject, and have all the several GetCommand calls not actually traverse through the alias to the underlying command object
The only times that an alias will be traversed are:
a) execution; when time comes to run an alias, I will just grab the underlying command and options, and make the interpreter execute that according to its current algorithm
b) subcommand traversal; if one has an alias to a multiword command, grabbing a subcommand will see through to the subcommand

Other operations, e.g. command listing, command names, command helps, ..., will all use the alias directly. This will, in turn, lead to the removal of the separate alias dictionary, and just mix user commands and aliases in one map

llvm-svn: 262986
2016-03-09 02:27:57 +00:00
Enrico Granata 7cf3b34d45 Add CommandAlias.cpp to CMakeLists
llvm-svn: 262959
2016-03-08 21:29:49 +00:00
Enrico Granata 937631cfdf Move CommandAlias to its own file; also
Store std::unique_ptr<CommandAlias> instead of instances

llvm-svn: 262958
2016-03-08 21:23:30 +00:00
Adrian Prantl 6aeba89e89 Support floating point values in 128-bit SSE vector registers
The System-V x86_64 ABI requires floating point values to be passed
in 128-but SSE vector registers (xmm0, ...). When printing such a
variable this currently yields an <invalid load address>.

This patch makes LLDB's DWARF expression evaluator accept 128-bit
registers as scalars. It also relaxes the check that the size of the
result of the DWARF expression be equal to the size of the variable to a
greater-than. DWARF defers to the ABI how smaller values are being placed
in a larger register.

Implementation note: I found the code in Value::SetContext() that changes
the m_value_type after the fact to be questionable. I added a sanity check
that the Value's memory buffer has indeed been written to (this is
necessary, because we may have a scalar value in a vector register), but
really I feel like this is the wrong place to be setting it.

Reviewed by Greg Clayton.

http://reviews.llvm.org/D17897
rdar://problem/24944340

llvm-svn: 262947
2016-03-08 18:35:09 +00:00
Tamas Berghammer 77b93ad471 Fix log in Broadcaster causing a crash
llvm-svn: 262925
2016-03-08 13:33:14 +00:00
Tamas Berghammer 65fa0b5169 Try to fix windows build after rL262863
llvm-svn: 262923
2016-03-08 11:43:56 +00:00
Ewan Crawford 1ab4adb1d3 Use c_str() instead of GetCString() to fix build
llvm-svn: 262920
2016-03-08 10:03:23 +00:00
Enrico Granata 443923b72d This is actually a FileSpec, so use .GetCString() instead
llvm-svn: 262914
2016-03-08 05:59:47 +00:00
Enrico Granata c8fd719e21 Use .c_str() here to unbreak the Linux build
llvm-svn: 262913
2016-03-08 05:57:52 +00:00
Enrico Granata 212130ac4d A few more improvements on the way to the command alias refactoring
- move alias help generation to CommandAlias, out of CommandInterpreter
- make alias creation use argument strings instead of OptionArgVectorSP; the former is a more reasonable currency than the latter
- remove m_is_alias from CommandObject, it wasn't actually being used

llvm-svn: 262912
2016-03-08 05:37:15 +00:00
Enrico Granata 002ab61a47 Turn GetAliasOptions() into GetAlias()
Eventually, there will be more things that CommandAlias contains, and I don't want accessors for each of them on the CommandIntepreter
Eventually, we also won't pass around copies of CommandAlias, but that's for a later patch

llvm-svn: 262909
2016-03-08 03:56:12 +00:00
Enrico Granata 4a795920e3 Attempt to fix the Ubuntu buildbot by making FindLongestCommandWord a free template function in lldb_private
llvm-svn: 262905
2016-03-08 03:48:41 +00:00
Jason Molenda 5df5402f94 Unbreak linux build broken by r262901
llvm-svn: 262904
2016-03-08 03:24:13 +00:00
Enrico Granata 5e5503099b Move ProcessAliasOptionsArgs to be a static on CommandAlias; it wasn't using any instance data on the CommandInterpreter anyway
This small step removes one piece of alias machinery from the CommandInterpreter into the CommandAlias

llvm-svn: 262901
2016-03-08 03:00:27 +00:00
Enrico Granata 308f73c5a3 Change the way command aliases are stored. Go from a model where a map holds the alias -> underlying command binding and another map holds the alias -> options, to a model where one single map holds the alias -> (all useful data) combination
Right now, obviously, this is just the pair of (CommandObjectSP,OptionArgVectorSP), so NFC

This is step one of a larger - and tricky - refactoring which will turn command aliases into interesting objects instead of passive storage that the command interpreter does smart things to
This refactoring, in turn, will allow us to do interesting things with aliases, such as intelligent and customizable help

llvm-svn: 262900
2016-03-08 02:49:15 +00:00
Jim Ingham 583bbb1dd4 Change over the broadcaster/listener process to hold shared or weak pointers
to each other.  This should remove some infrequent teardown crashes when the
listener is not the debugger's listener.

Processes now need to take a ListenerSP, not a Listener&.

This required changing over the Process plugin class constructors to take a ListenerSP, instead
of a Listener&.   Other than that there should be no functional change.
 
<rdar://problem/24580184> CrashTracer: [USER] Xcode at …ework: lldb_private::Listener::BroadcasterWillDestruct + 39

llvm-svn: 262863
2016-03-07 21:50:25 +00:00
James Y Knight dc395b9d2b Update after r262737 in clang changed the accessor.
llvm-svn: 262739
2016-03-04 19:30:53 +00:00
Pavel Labath 16d3fd8ba1 Fix warning in IRExecutionUnit.cpp
llvm-svn: 262712
2016-03-04 11:26:56 +00:00
Tamas Berghammer b0b1ea36e7 Add reverse file remapping for breakpoint set
LLDB can remap a source file to a new directory based on the
"target.sorce-map" to handle the usecase when the source code moved
between the compliation and the debugging. Previously the remapping
was only used to display the content of the file. This CL fixes the
scenario when a breakpoint is set based on the new an absolute path
with adding an inverse remapping step before looking up the breakpoint
location.

Differential revision: http://reviews.llvm.org/D17848

llvm-svn: 262711
2016-03-04 11:26:44 +00:00
Eugene Zelenko 34ede34acd Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes.
llvm-svn: 262570
2016-03-03 00:51:40 +00:00
Zachary Turner 74e08ca05c Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.

Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows.  This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.

This patch only adds support for line tables.  It does not return
information about functions, types, global variables, or anything
else.  This functionality will be added in a followup patch.

Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton

llvm-svn: 262528
2016-03-02 22:05:52 +00:00
Tamas Berghammer 45dbfa1f83 Upgrade the arm/thumb architecture used by the disassembler
Previously we were using thumbv7 and armv8.1a what ended up showing a
few undefined instruction when disassembling code. This CL update the
architectures used to armv8.2a and thumbv8.2a (newest available) so we
display all instruction in the disassambly.

llvm-svn: 262482
2016-03-02 12:42:43 +00:00
Eugene Zelenko df37055017 Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes.
llvm-svn: 262450
2016-03-02 02:18:18 +00:00
Eugene Zelenko 896ddd03e9 Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes.
llvm-svn: 262441
2016-03-02 01:09:03 +00:00
Ted Woodward 7071c5fd64 Fix bug with function resolution when using IR Interpreter
Summary: Recent changes to the expression parser broke function name resolution when using the IR interpreter instead of JIT. This patch changes the IRMemoryMap ivar in InterpreterStackFrame to an IRExecutionUnitSP (which is a subclass), allowing InterpreterStackFrame::ResolveConstantValue() to call FindSymbol() on the name of the Value when it's a FunctionVal. It also changes IRExecutionUnit::FindInSymbols() to call GetFileAddress() on the symball if ResolveCallableAddress() fails and there is no valid Process.

Reviewers: spyffe

Subscribers: lldb-commits

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

llvm-svn: 262407
2016-03-01 21:53:26 +00:00
Tamas Berghammer f46c5259bd DWARFExpression: Don't resolve load address in DW_OP_plus
If we have a TargetLoadAddress on the top of the DWARF stack then a
DW_OP_plus or a DW_OP_plus_ucons sholudn't dereference (resolve) it
and then add the value to the dereferenced value but it should offset
the load address by the specified constant.

llvm-svn: 262339
2016-03-01 15:01:05 +00:00
Pavel Labath 109702ccb1 Fix warning in NSDictionary.cpp
llvm-svn: 262322
2016-03-01 11:40:47 +00:00
Jason Molenda cc9e92eb41 Update the on-device arm specific code to match the API changes
that happened in other parts of this file so it builds cleanly
for arm again.

llvm-svn: 262300
2016-03-01 05:34:05 +00:00
Eugene Zelenko 9b0a801797 Fix MSVC build failure in source/Target/Process.cpp.
Will be good idea to introduce macro/constexpr for NULL thread_result_t.

llvm-svn: 262287
2016-03-01 02:08:37 +00:00
Eugene Zelenko da8cf8af35 Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target/Process.cpp; other minor fixes.
llvm-svn: 262281
2016-03-01 00:55:51 +00:00
Enrico Granata 46d4aa211f When 'help' cannot find a command, produce additional help text that also points the user to the apropos and type lookup commands
This is useful in cases such as, e.g.

(lldb) help NSString
(the user meant type lookup)

or

(lldb) help kill
(the user is looking for process kill)

Fixes rdar://24868537

llvm-svn: 262271
2016-02-29 23:22:53 +00:00
Enrico Granata fe09d5e73a Fix a typo in my previous commit. This would cause mutable NSArrays to show up empty
llvm-svn: 262260
2016-02-29 21:41:19 +00:00
Enrico Granata 7a67ee263f Change the user-visible name for the argument type language to source-language
This makes it so that help language provides help on the language command and help source-language provides the list of source languages one can pass as an option

Fixes rdar://24869942

llvm-svn: 262259
2016-02-29 21:37:01 +00:00
Adrian McCarthy a7ad58b61c NFC: Refactor ProcessWinMiniDump to use a more traditional pimpl idiom.
This is a mechanical refactor.  There should be no functional changes in this commit.

Instead of encapsulating just the Windows-specific data, ProcessWinMiniDump now uses a private implementation class.  This reduces indirections (in the source).  It makes it easier to add private helper methods without touching the header and allows them to have platform-specific types as parameters.  The only trick was that the pimpl class needed a back pointer in order to call a couple methods.

llvm-svn: 262256
2016-02-29 21:15:23 +00:00
Enrico Granata 936499ae4c Add an LLDB data formatter for single-element NSArray and NSDictionary Cocoa containers
Fixes rdar://23715118

llvm-svn: 262254
2016-02-29 21:06:50 +00:00
Eugene Zelenko bbd16815b0 Fix Clang-tidy modernize-use-nullptr warnings in source/Plugins/Language; other minor fixes.
llvm-svn: 262246
2016-02-29 19:41:30 +00:00
Omair Javaid ef77ace9ae Add/Improve complex, vector, aggregate types handling for SysV ARM (hard/soft) ABI.
For details see:

Differential revision: http://reviews.llvm.org/D17708

llvm-svn: 262218
2016-02-29 13:39:20 +00:00
Pavel Labath 76d76bb006 Fix compiler warnings in the java code
llvm-svn: 262214
2016-02-29 11:44:15 +00:00
Todd Fiala 6993abff14 Revert "Fix bug with register values byte order in expression evaluation."
This reverts commit r262041, which caused asserts starting yesterday on the OS X testbot.

See details in:
https://llvm.org/bugs/show_bug.cgi?id=26758

llvm-svn: 262156
2016-02-27 22:48:50 +00:00
Greg Clayton cc2e27f098 Make LLDB safer to use with respect to the global destructor chain.
llvm-svn: 262090
2016-02-26 23:20:08 +00:00
Eugene Zelenko 4ea4d2ed30 Fix Clang-tidy modernize-use-nullptr warnings in remaining files in source/Plugins/ABI; other minor fixes.
llvm-svn: 262082
2016-02-26 22:26:21 +00:00
Chaoren Lin b6f76b3d47 Register value is not necessarily scalar.
Reviewers: aidan.dodds, mamai

Subscribers: lldb-commits

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

llvm-svn: 262081
2016-02-26 22:12:35 +00:00
Greg Clayton 5cc45e0122 Make sure to #include <atomic> for the std::atomic<bool> that was recently added.
llvm-svn: 262055
2016-02-26 19:41:49 +00:00
Greg Clayton 04df8ee55e Make sure the Target, Process and Thread GetGlobalProperties() static methods are thread safe.
<rdar://problem/22595283>

llvm-svn: 262053
2016-02-26 19:38:18 +00:00
Jim Ingham 406ba45f24 SymbolFileDWARFDebugMap::FindTypes didn't obey the max_matches flag,
but kept looking through .o files even after it had found as many 
matches as were requested.

llvm-svn: 262051
2016-02-26 19:33:11 +00:00
Aidan Dodds 3cdf5516c6 remove unused local string in IRForTarget.cpp
Committed on behalf of: ldrumm <luke.drummond@codeplay.com>

Differential revision: http://reviews.llvm.org/D16412

llvm-svn: 262043
2016-02-26 18:03:06 +00:00
Aidan Dodds 5ba2b2af6e Fix bug with register values byte order in expression evaluation.
The evaluation of expressions containing register values was broken for targets for which endianness differs from host.

Committed on behalf of: mamai <marianne.mailhot.sarrasin@gmail.com>

Differential revision: http://reviews.llvm.org/D17167

llvm-svn: 262041
2016-02-26 17:40:50 +00:00
Greg Clayton 860582f78e The IOHandlerProcessSTDIO is the _only_ IOHandler that gets pushed and popped from functions that are run due to something that is NOT input from the user. All other IOHandler objects result from input from the user. An issue rose up where if a command caused the process to resume and stop and process state changed, where state changed Event objects were broadcast, it would cause the IOHandlerProcessSTDIO to have its IOHandlerProcessSTDIO::Cancel() function called. This used to always write a byte to the control pipe (IOHandlerProcessSTDIO::m_pipe) even if the IOHandlerProcessSTDIO::Run() was never called. What would happen is:
(lldb) command_that_steps_process_thousands_of_times

As the "command_that_steps_process_thousands_of_times" could be a python command that resumed the process thousands of times and in doing so the IOHandlerProcessSTDIO would get pushed when the process resumed, and popped when it stoppped, causing the call to IOHandlerProcessSTDIO::Cancel(). Since the IOHandler thread is currently in IOHandlerEditline::Run() for the command interpreter handling the "command_that_steps_process_thousands_of_times" command, IOHandlerProcessSTDIO::Run() would never get called, even though the IOHandlerProcessSTDIO is on the top of the stack. This caused the command pipe to keep getting 1 bytes written each time the IOHandlerProcessSTDIO::Cancel() was called and eventually we will deadlock since the write buffer is full.

The fix here is to make sure we are in IOHandlerProcessSTDIO::Run() before we write anything to the command pipe, and just call SetIsDone(true) if we are not.

<rdar://problem/22361364>

llvm-svn: 262040
2016-02-26 17:36:44 +00:00
Tamas Berghammer 0ed9c497ca Revert part of rL262014 as it caused issues on gcc-i386
llvm-svn: 262023
2016-02-26 15:33:32 +00:00
Aidan Dodds 7f6e9d53a3 Add mips32 software breakpoints into platform::GetSoftwareBreakpointTrapOpcode().
The software breakpoint definitions for mips32 should have been included in my
recent patch that moved the software breakpoint definitions into the base platform
class.

llvm-svn: 262021
2016-02-26 15:11:01 +00:00
Tamas Berghammer 31d315b349 Fix address class lookup for absolute symbols
llvm-svn: 262016
2016-02-26 14:21:27 +00:00