summaryrefslogtreecommitdiffstats
path: root/lldb/source/Utility
Commit message (Collapse)AuthorAgeFilesLines
* Work around a linux libc bug causing a crash in TaskPoolPavel Labath2016-04-151-2/+3
| | | | | | | | | | | | | | | | | | 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
* Fixed an issue that could cause debugserver to return two stop reply packets ↵Greg Clayton2016-04-012-5/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ($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
* Fix all of the unannotated switch cases to annotate the fall through or do ↵Greg Clayton2016-02-262-1/+2
| | | | | | the right thing and break. llvm-svn: 261950
* Add support for handling absolute symbols in ELFTamas Berghammer2016-02-251-0/+2
| | | | | | | | | | | | | | | Most address represented in lldb as section plus offset and handling of absolute addresses is problematic in several location because of lack of necessary information (e.g. Target) or because of performance issues. This CL change the way ObjectFileELF handle the absolute symbols with creating a pseudo section for each symbol. With this change all existing code designed to work with addresses in the form of section plus offset will work with absolute symbols as well. Differential revision: http://reviews.llvm.org/D17450 llvm-svn: 261859
* Remove autoconf support from source directories.Eugene Zelenko2016-01-281-15/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
* Read macro info from .debug_macro section and use it for expression evaluation.Siva Chandra2015-12-161-0/+2
| | | | | | | | | | | | | | | | | Summary: DWARF 5 proposes a reinvented .debug_macro section. This change follows that spec. Currently, only GCC produces the .debug_macro section and hence the added test is annottated with expectedFailureClang. Reviewers: spyffe, clayborg, tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D15437 llvm-svn: 255729
* Add failure paths to a few JSONNumber membersOmair Javaid2015-12-141-1/+5
| | | | | | Differential revision: http://reviews.llvm.org/D15355 llvm-svn: 255499
* Add modules downloaded by ModuleCache to the global ModuleListTamas Berghammer2015-12-101-5/+11
| | | | | | | | | | | | | Adding the modules to the global module list eleminate issues in the case when a module is unloaded from the target but some object (e.g. breakpoint) still referencing them with weak pointers. It also speeds up the case when we load, unload, load the same shared library because the global module cache will keep the parsed debug info around between the 2 load (this scenario happens for some code on android). Differential revision: http://reviews.llvm.org/D15415 llvm-svn: 255260
* Modify "platform connect" to connect to processes as wellTamas Berghammer2015-12-082-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | The standard remote debugging workflow with gdb is to start the application on the remote host under gdbserver (e.g.: gdbserver :5039 a.out) and then connect to it with gdb. The same workflow is supported by debugserver/lldb-gdbserver with a very similar syntax but to access all features of lldb we need to be connected also to an lldb-platform instance running on the target. Before this change this had to be done manually with starting a separate lldb-platform on the target machine and then connecting to it with lldb before connecting to the process. This change modifies the behavior of "platform connect" with automatically connecting to the process instance if it was started by the remote platform. With this command replacing gdbserver in a gdb based worflow is usually as simple as replacing the command to execute gdbserver with executing lldb-platform. Differential revision: http://reviews.llvm.org/D14952 llvm-svn: 255016
* Improve the functionality of JSONNumberTamas Berghammer2015-12-041-24/+59
| | | | | | | | | * Add support for representing signed integers * Add new constructors taking any signed or unsigned integer types Differential revision: http://reviews.llvm.org/D15187 llvm-svn: 254715
* Fix module cache sym links' creation for symbol files.Oleksiy Vyalov2015-11-031-2/+2
| | | | | | http://reviews.llvm.org/D14264 llvm-svn: 251871
* Add a new task pool class to LLDBTamas Berghammer2015-10-202-0/+89
| | | | | | | | | | | | | | | | | | | | | | The purpose of the class is to make it easy to execute tasks in parallel Basic design goals: * Have a very lightweight and easy to use interface where a list of lambdas can be executed in parallel * Use a global thread pool to limit the number of threads used (std::async don't do it on Linux) and to eliminate the thread creation overhead * Destroy the thread currently not in use to avoid the confusion caused by them during debugging LLDB Possible future improvements: * Possibility to cancel already added, but not yet started tasks * Parallel for_each implementation * Optimizations in the thread creation destroyation code Differential revision: http://reviews.llvm.org/D13727 llvm-svn: 250820
* lldb-server: add support for binary memory readsPavel Labath2015-10-142-0/+8
| | | | | | | | | | | | | | | | | Summary: This commit adds support for binary memory reads ($x) to lldb-server. It also removes the "0x" prefix from the $x client packet, to make it more compatible with the old $m packet. This allows us to use almost the same code for handling both packet types. I have verified that debugserver correctly handles $x packets even without the leading "0x". I have added a test which verifies that the stub returns the same memory contents for both kinds of memory reads ($x and $m). Reviewers: tberghammer, jasonmolenda Subscribers: iancottrell, lldb-commits Differential Revision: http://reviews.llvm.org/D13695 llvm-svn: 250295
* Add support for .ARM.exidx unwind informationTamas Berghammer2015-09-301-0/+4
| | | | | | | | | .ARM.exidx/.ARM.extab sections contain unwind information used on ARM architecture from unwinding from an exception. Differential revision: http://reviews.llvm.org/D13245 llvm-svn: 248903
* Add comment in StringExtractor::GetHexU8Dawn Perchik2015-09-251-1/+3
| | | | llvm-svn: 248601
* Remove unused modules from module cache.Oleksiy Vyalov2015-09-181-20/+114
| | | | | | http://reviews.llvm.org/D12971 llvm-svn: 248017
* Fix LLDB RSP client to decode '$O' packets incorrectlyDawn Perchik2015-09-171-2/+11
| | | | | | | | | | | | Character with ASCII code 0 is incorrectly treated by LLDB as the end of RSP packet. The left of the debugger server output is silently ignored. Patch from evgeny.leviant@gmail.com Reviewed by: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12523 llvm-svn: 247908
* Add an OperatingSystem plugin to support goroutinesRyan Brown2015-09-161-0/+2
| | | | | | | | | | The Go runtime schedules user level threads (goroutines) across real threads. This adds an OS plugin to create memory threads for goroutines. It supports the 1.4 and 1.5 go runtime. Differential Revision: http://reviews.llvm.org/D5871 llvm-svn: 247852
* Clean up register naming conventions inside lldb. Jason Molenda2015-09-153-157/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "gcc" register numbers are now correctly referred to as "ehframe" register numbers. In almost all cases, ehframe and dwarf register numbers are identical (the one exception is i386 darwin where ehframe regnums were incorrect). The old "gdb" register numbers, which I incorrectly thought were stabs register numbers, are now referred to as "Process Plugin" register numbers. This is the register numbering scheme that the remote process controller stub (lldb-server, gdbserver, core file support, kdp server, remote jtag devices, etc) uses to refer to the registers. The process plugin register numbers may not be contiguous - there are remote jtag devices that have gaps in their register numbering schemes. I removed all of the enums for "gdb" register numbers that we had in lldb - these were meaningless - and I put LLDB_INVALID_REGNUM in all of the register tables for the Process Plugin regnum slot. This change is almost entirely mechnical; the one actual change in here is to ProcessGDBRemote.cpp's ParseRegisters() which parses the qXfer:features:read:target.xml response. As it parses register definitions from the xml, it will assign sequential numbers as the eRegisterKindLLDB numbers (the lldb register numberings must be sequential, without any gaps) and if the xml file specifies register numbers, those will be used as the eRegisterKindProcessPlugin register numbers (and those may have gaps). A J-Link jtag device's target.xml does contain a gap in register numbers, and it only specifies the register numbers for the registers after that gap. The device supports many different ARM boards and probably selects different part of its register file as appropriate. http://reviews.llvm.org/D12791 <rdar://problem/22623262> llvm-svn: 247741
* [cmake] Remove LLVM_NO_RTTI.Bruce Mitchener2015-09-031-2/+0
| | | | | | | | | | | | | | Summary: This doesn't exist in other LLVM projects any longer and doesn't do anything. Reviewers: chaoren, labath Subscribers: emaste, tberghammer, lldb-commits, danalbert Differential Revision: http://reviews.llvm.org/D12586 llvm-svn: 246749
* Simplify find_first_of & find_last_of on single char.Bruce Mitchener2015-09-011-1/+1
| | | | | | | | | | | | | | | Summary: When calling find_first_of and find_last_of on a single character, we can instead just call find / rfind and make our intent more clear. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12518 llvm-svn: 246609
* Add support for DW_FORM_GNU_[addr,str]_indexTamas Berghammer2015-08-251-0/+4
| | | | | | | | | These are 2 new value currently in experimental status used when split debug info is enabled. Differential revision: http://reviews.llvm.org/D12238 llvm-svn: 245931
* Make UriParser to support [$HOSTNAME] notation.Oleksiy Vyalov2015-08-202-36/+64
| | | | | | http://reviews.llvm.org/D12025 llvm-svn: 245639
* A messy bit of cleanup: Move towards more descriptive namesJason Molenda2015-08-152-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for eh_frame and stabs register numberings. This is not complete but it's a step in the right direction. It's almost entirely mechanical. lldb informally uses "gcc register numbering" to mean eh_frame. Why? Probably because there's a notorious bug with gcc on i386 darwin where the register numbers in eh_frame were incorrect. In all other cases, eh_frame register numbering is identical to dwarf. lldb informally uses "gdb register numbering" to mean stabs. There are no official definitions of stabs register numbers for different architectures, so the implementations of gdb and gcc are the de facto reference source. There were some incorrect uses of these register number types in lldb already. I fixed the ones that I saw as I made this change. This commit changes all references to "gcc" and "gdb" register numbers in lldb to "eh_frame" and "stabs" to make it clear what is actually being represented. lldb cannot parse the stabs debug format, and given that no one is using stabs any more, it is unlikely that it ever will. A more comprehensive cleanup would remove the stabs register numbers altogether - it's unnecessary cruft / complication to all of our register structures. In ProcessGDBRemote, when we get register definitions from the gdb-remote stub, we expect to see "gcc:" (qRegisterInfo) or "gcc_regnum" (qXfer:features:read: packet to get xml payload). This patch changes ProcessGDBRemote to also accept "ehframe:" and "ehframe_regnum" from these remotes. I did not change GDBRemoteCommunicationServerLLGS or debugserver to send these new packets. I don't know what kind of interoperability constraints we might be working under. At some point in the future we should transition to using the more descriptive names. Throughout lldb we're still using enum names like "gcc_r0" and "gdb_r0", for eh_frame and stabs register numberings. These should be cleaned up eventually too. The sources link cleanly on macosx native with xcode build. I don't think we'll see problems on other platforms but please let me know if I broke anyone. llvm-svn: 245141
* There is no such thing as gdb_arm_f8, this register set is f0-f7.Jason Molenda2015-08-151-83/+82
| | | | | | | Remove this entry and adjust the numbering for the rest of the arm register definitions. llvm-svn: 245130
* Download symbol file for .oat files on androidTamas Berghammer2015-08-122-10/+49
| | | | | | | | | | | | | On android .oat files (compiled java code) don't have symbol information but on SDK 23+ it can be generated by the oatdump tool (based on the dex information). This CL adds logic to download this information and store it in the module cache. Differential revision: http://reviews.llvm.org/D11936 llvm-svn: 244738
* Fix jSignalsInfo packet handling.Oleksiy Vyalov2015-07-271-1/+1
| | | | llvm-svn: 243257
* Fix typos.Bruce Mitchener2015-07-222-2/+2
| | | | | | | | | | | | Summary: Fix a bunch of typos. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11386 llvm-svn: 242856
* Add jThreadsInfo support to lldb-serverPavel Labath2015-07-162-1/+4
| | | | | | | | | | | | | | | Summary: This commit adds initial support for the jThreadsInfo packet to lldb-server. The current implementation does not expedite inferior memory. I have also added a description of the new packet to our protocol documentation (mostly taken from Greg's earlier commit message). Reviewers: clayborg, ovyalov, tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11187 llvm-svn: 242402
* Refactor Unix signals.Chaoren Lin2015-07-142-2/+8
| | | | | | | | | | | | | | | | | | Summary: - Consolidate Unix signals selection in UnixSignals. - Make Unix signals available from platform. - Add jSignalsInfo packet to retrieve Unix signals from remote platform. - Get a copy of the platform signal for each remote process. - Update SB API for signals. - Update signal utility in test suite. Reviewers: ovyalov, clayborg Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11094 llvm-svn: 242101
* Fix cmake build after recent JSON changesPavel Labath2015-07-074-178/+4
| | | | | | | I have moved StringExtractor.h into the include/ folder so that it can be properly included by everyone. llvm-svn: 241572
* Make the "lldb/Utility/JSON.h" able to parse JSON into tokens with the new ↵Greg Clayton2015-07-063-17/+472
| | | | | | | | | | JSONParser class. Change over existing code to use this new parser so StructuredData can use the tokenizer to parse JSON instead of doing it manually. This allowed us to easily parse JSON into JSON* objects as well as into StructuredData. llvm-svn: 241522
* Fetch object file load address if it isn't specified by the linkerTamas Berghammer2015-06-182-0/+5
| | | | | | Differential revision: http://reviews.llvm.org/D10490 llvm-svn: 240052
* Refactor many file functions to use FileSpec over strings.Chaoren Lin2015-05-291-3/+2
| | | | | | | | | | | | | | | | | Summary: This should solve the issue of sending denormalized paths over gdb-remote if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the server handle any denormalization. Reviewers: ovyalov, zturner, vharron, clayborg Reviewed By: clayborg Subscribers: tberghammer, emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D9728 llvm-svn: 238604
* Add support for the qEcho command to lldb-server in the common packets.Greg Clayton2015-05-292-0/+5
| | | | llvm-svn: 238533
* Remote Non-Stop SupportEwan Crawford2015-05-132-0/+5
| | | | | | | | | | | | | | | | | | | | Summary: This patch is the beginnings of support for Non-stop mode in the remote protocol. Letting a user examine stopped threads, while other threads execute freely. Non-stop mode is enabled using the setting target.non-stop-mode, which sends a QNonStop packet when establishing the remote connection. Changes are also made to treat the '?' stop reply packet differently in non-stop mode, according to spec https://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop. A setting for querying the remote for default thread on setup is also included. Handling of '%' async notification packets will be added next. Reviewers: clayborg Subscribers: lldb-commits, ADodds, ted, deepak2427 Differential Revision: http://reviews.llvm.org/D9656 llvm-svn: 237239
* Get lldb-server building on android-9Vince Harron2015-05-121-0/+1
| | | | | | Build lldb-server with an android-9 sysroot. llvm-svn: 237078
* Use hard links to link sysroot files within ModuleCache.Oleksiy Vyalov2015-05-082-42/+31
| | | | | | http://reviews.llvm.org/D9587 llvm-svn: 236917
* Have lldb_assert accept bool expressionsPavel Labath2015-05-081-1/+1
| | | | | | | | | | | | | | | Summary: This changes lldb_assert to accept bool expressions as the parameter, this is because some objects (such as std::shared_ptr) are convertible to bool, but are not convertible to int, which leads to surprising errors. Reviewers: granata.enrico, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9565 llvm-svn: 236819
* Use file locks to synchronize access to ModuleCache.Oleksiy Vyalov2015-05-072-38/+45
| | | | | | http://reviews.llvm.org/D9056 llvm-svn: 236736
* Add Modulecache::GetAndPut method which wraps sequence of Get and Put (if ↵Oleksiy Vyalov2015-04-152-0/+50
| | | | | | | | module wasn't found in cache) calls. http://reviews.llvm.org/D9013 llvm-svn: 235011
* Fix warnings generated by clang-cl.Zachary Turner2015-04-021-3/+3
| | | | | | | | | | | | | | There were a couple of real bugs here regarding error checking and signed/unsigned comparisons, but mostly these were just noise. There was one class of bugs fixed here which is particularly annoying, dealing with MSVC's non-standard behavior regarding the underlying type of enums. See the comment in lldb-enumerations.h for details. In short, from now on please use FLAGS_ENUM and FLAGS_ANONYMOUS_ENUM when defining enums which contain values larger than can fit into a signed integer. llvm-svn: 233943
* Fix ModuleCache usage in Platform - ask remote platform for module's ↵Oleksiy Vyalov2015-03-242-2/+6
| | | | | | | | ModuleSpec beforehand so we can look for a module by UUID locally without need to download it. http://reviews.llvm.org/D8557 llvm-svn: 233136
* Move some functions from source/lldb.cpp to Utility.Zachary Turner2015-03-183-0/+162
| | | | | | | | | | Specifically, there were some functions for converting enums to strings and a function for matching a string using a specific matching algorithm. This moves those functions to more appropriate headers in lldb/Utility and updates references to include the new headers. llvm-svn: 232673
* Silence warnings here by explicit cast.Enrico Granata2015-03-131-2/+2
| | | | llvm-svn: 232126
* Make ModuleCache::Get to return instantiated ModuleSP instance so already ↵Oleksiy Vyalov2015-03-122-25/+36
| | | | | | | | created in-memory instance can be returned instead of creating a new one. http://reviews.llvm.org/D8270 llvm-svn: 232075
* Add Utility/ModuleCache class and integrate it with PlatformGDBRemoteServer ↵Oleksiy Vyalov2015-03-103-0/+205
| | | | | | | | - in order to allow modules caching from remote targets. http://reviews.llvm.org/D8037 llvm-svn: 231734
* Remove Host::Backtrace in favor of llvm::sys::PrintStackTrace()Zachary Turner2015-03-061-12/+10
| | | | | | | | | | | | This removes Host::Backtrace from the codebase, and changes all call sites to use llvm::sys::PrintStackTrace(). This makes the functionality available for all platforms, and even for platforms which currently had a supported implementation of Host::Backtrace, this patch should enable richer information in stack traces, such as file and line number information, as well as giving it the ability to unwind through inlined functions. llvm-svn: 231511
* Appease the Windows botEnrico Granata2015-03-041-0/+1
| | | | llvm-svn: 231315
* Introduce lldbassert(x)Enrico Granata2015-03-041-0/+38
| | | | | | | | | | | We would like it if LLDB never crashed, especially if we never caused LLDB to crash On the other hand, having assertions can sometimes be useful lldbassert(x) is the best of both worlds: - in debug builds, it turns into a regular assert, which is fine because we don't mind debug LLDB to crash on development machines - in non-debug builds, it emits a message formatted just like assert(x) would, but then instead of crashing, it dumps a backtrace, suggests filing a bug, and keeps running llvm-svn: 231310
OpenPOWER on IntegriCloud