summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ObjectFile/ELF
Commit message (Collapse)AuthorAgeFilesLines
...
* [linux] Change the way we load vdso pseudo-modulePavel Labath2017-06-202-94/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is basically a revert of D16107 and parts of D10800, which were trying to get vdso loading working. They did this by implementing a generic load-an-elf-file from memory approach, which is not correct, since we cannot assume that an elf file is loaded in memory in full (it usually isn't, as there's no need to load section headers for example). This meant that we would read garbage instead of section sizes, and if that garbage happened to be a large number, we would crash while trying to allocate a buffer to accomodate the hypothetical section. Instead of this, I add a bit of custom code to load the vdso to DynamicLoaderPOSIXDYLD (which already needed to handle the vdso specially). I determine the size of the memory to read using Process::GetMemoryRegionInfo, which is information coming from the OS, and cannot be forged by a malicious/misbehaving application. Reviewers: eugene, clayborg Subscribers: lldb-commits, ravitheja, tberghammer, emaste Differential Revision: https://reviews.llvm.org/D34352 llvm-svn: 305780
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-072-1/+2
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* Remove an expensive lock from TimerPavel Labath2017-05-151-1/+2
| | | | | | | | | | | | | The Timer destructor would grab a global mutex in order to update execution time. Add a class to define a category once, statically; the class adds itself to an atomic singly linked list, and thus subsequent updates only need to use an atomic rather than grab a lock and perform a hashtable lookup. Differential Revision: https://reviews.llvm.org/D32823 Patch by Scott Smith <scott.smith@purestorage.com>. llvm-svn: 303058
* Rename Error -> Status.Zachary Turner2017-05-122-6/+6
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* ObjectFileELF: Fix symbol lookup in bss sectionPavel Labath2017-05-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: If we have symbol information in a separate file, we need to be very careful about presenting a unified section view of module to the rest of the debugger. ObjectFileELF had code to handle that, but it was being overly cautious -- the section->GetFileSize()!=0 meant that the unification would fail for sections which do not occupy any space in the object file (e.g., .bss). In my case, that manifested itself as not being able to display the values of .bss variables properly as the section associated with the variable did not have it's load address set (because it was not present in the unified section list). I test this by making sure the unified section list and the variables refer to the same section. Reviewers: eugene, zturner Subscribers: tberghammer, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D32434 llvm-svn: 301917
* Change UniqueCStringMap to use ConstString as the keyPavel Labath2017-05-022-3/+3
| | | | | | | | | | | | | | | | Summary: UniqueCStringMap "sorts" the entries for fast lookup, but really it only cares about uniqueness. ConstString can be compared by pointer alone, rather than with strcmp, resulting in much faster comparisons. Change the interface to take ConstString instead, and propagate use of the type to the callers where appropriate. Reviewers: #lldb, clayborg Reviewed By: clayborg Subscribers: labath, jasonmolenda, lldb-commits Differential Revision: https://reviews.llvm.org/D32316 Patch by Scott Smith <scott.smith@purestorage.com>. llvm-svn: 301908
* [LLDB][MIPS] Fix Core file Architecture and OS information.Nitesh Jain2017-03-311-4/+30
| | | | | | | | | | Reviewers: labath, clayborg Subscribers: jaydeep, bhushan, lldb-commits, slthakur Differential Revision: https://reviews.llvm.org/D31280 llvm-svn: 299199
* [LLDB] OpenBSD supportKamil Rytarowski2017-03-261-2/+9
| | | | | | | | | | | | | | | | | | | | Summary: Add basic OpenBSD support. This is enough to be able to analyze core dumps for OpenBSD/amd64, OpenBSD/arm, OpenBSD/arm64 and OpenBSD/i386. Note that part of the changes to source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp fix a bug that probably affects other platforms as well. The GetProgramHeaderByIndex() interface use 1-based indices, but in some case when looping over the headers the, the loop starts at 0 and misses the last header. This caused problems on OpenBSD since OpenBSD core dumps have the PT_NOTE segment as the last program header. Reviewers: joerg, labath, krytarowski Reviewed By: krytarowski Subscribers: aemerson, emaste, rengolin, srhines, krytarowski, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D31131 llvm-svn: 298810
* Move FileSpec from Host -> Utility.Zachary Turner2017-03-221-2/+2
| | | | llvm-svn: 298536
* Remove FileSpec::ReadFileContents.Zachary Turner2017-03-061-7/+7
| | | | | | | | | | | | | | | | This functionality is subsumed by DataBufferLLVM, which is also more efficient since it will try to mmap. However, we don't yet support mmaping writable private sections, and in some cases we were using ReadFileContents and then modifying the buffer. To address that I've added a flag to the DataBufferLLVM methods that allow you to map privately, which disables the mmaping path entirely. Eventually we should teach DataBufferLLVM to use mmap with writable private, but that is orthogonal to this effort. Differential Revision: https://reviews.llvm.org/D30622 llvm-svn: 297095
* Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner2017-03-042-14/+16
| | | | llvm-svn: 296943
* Move UUID from Core -> Utility.Zachary Turner2017-03-041-1/+1
| | | | llvm-svn: 296941
* Move Log from Core -> Utility.Zachary Turner2017-03-031-1/+1
| | | | | | | | | All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
* Delete DataBufferMemoryMap.Zachary Turner2017-02-241-46/+61
| | | | | | | | | | | | | | | After a series of patches on the LLVM side to get the mmaping code up to compatibility with LLDB's needs, it is now ready to go, which means LLDB's custom mmapping code is redundant. So this patch deletes it all and uses LLVM's code instead. In the future, we could take this one step further and delete even the lldb DataBuffer base class and rely entirely on LLVM's facilities, but this is a job for another day. Differential Revision: https://reviews.llvm.org/D30054 llvm-svn: 296159
* Move classes from Core -> Utility.Zachary Turner2017-02-022-3/+3
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Open ELF core dumps with more than 64K sectionsPavel Labath2017-01-313-8/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Problem: There are three filelds in the ELF header - e_phnum, e_shnum, and e_shstrndx - that could be bigger than 64K and therefore do not fit in 16 bits reserved for them in the header. If this happens, pretty often there is a special section at index 0 which contains their real values for these fields in the section header in the fields sh_info, sh_size, and sh_link respectively. Fix: - Rename original fields in the header declaration. We want to have them around just in case. - Reintroduce these fields as 32-bit members at the end of the header. By default they are initialized from the header in Parse() method. - In Parse(), detect the situation when the header might have been extended into section info #0 and try to read it from the same data source. - ObjectFileELF::GetModuleSpecifications accesses some of these fields but the original parse uses too small data source. Re-parse the header if necessary using bigger data source. - ProcessElfCore::CreateInstance uses header with potentially sentinel values, but it does not access these fields, so a comment here is enough. Reviewers: labath Reviewed By: labath Subscribers: davidb, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D29095 Author: Eugene Birukov <eugenebi@hotmail.com> llvm-svn: 293714
* [CMake] [2/4] Update a batch of pluginsChris Bieneman2017-01-311-1/+9
| | | | | | This is extending the updates from r293696 to more LLDB plugins. llvm-svn: 293699
* Fix more unused variable warnings when asserts are disabled.Hafiz Abid Qadeer2017-01-201-0/+2
| | | | llvm-svn: 292598
* [lldb] Update the check for Linux or FreeBSD in SymbolFileDWARF::FindFunctionsAlexander Shaposhnikov2016-12-051-2/+8
| | | | | | | | | | | | | | | | | | | This diff 1. Adds a comment to ObjectFileELF.cpp about the current approach to determining the OS. 2. Replaces the check in SymbolFileDWARF.cpp with a more robust one. Test plan: Built (on Linux) a test binary linked to a c++ shared library which contains just an implementation of a function TestFunction, the library (the binary itself) doesn't contain ELF notes and EI_OSABI is set to System V. Checked in lldb that now "p TestFunction()" works fine (and doesn't work without this patch). Differential revision: https://reviews.llvm.org/D27380 llvm-svn: 288687
* Fix Clang-tidy readability-redundant-string-cstr warningsMalcolm Parsons2016-11-021-1/+1
| | | | | | | | | | Reviewers: zturner, labath Subscribers: tberghammer, danalbert, lldb-commits Differential Revision: https://reviews.llvm.org/D26233 llvm-svn: 285855
* [lldb] Improve identification of Linux core dumps. Fix for bug #30485.Richard Chamberlain2016-10-131-2/+1
| | | | | | | | | | | | | | | Summary: ObjectFileELF::RefineModuleDetailsFromNote() identifies Linux core dumps by searching for library paths starting with /lib/x86_64-linux-gnu or /lib/i386-linux-gnu. This change widens the test to allow for linux installations which have addition directories in the path. Reviewers: ted, hhellyer, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D25179 llvm-svn: 284114
* Fix about a dozen compile warningsIlia K2016-09-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | Summary: It fixes the following compile warnings: 1. '0' flag ignored with precision and ‘%d’ gnu_printf format 2. enumeral and non-enumeral type in conditional expression 3. format ‘%d’ expects argument of type ‘int’, but argument 4 has type ... 4. enumeration value ‘...’ not handled in switch 5. cast from type ‘const uint64_t* {aka ...}’ to type ‘int64_t* {aka ...}’ casts away qualifiers 6. extra ‘;’ 7. comparison between signed and unsigned integer expressions 8. variable ‘register_operand’ set but not used 9. control reaches end of non-void function Reviewers: jingham, emaste, zturner, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D24331 llvm-svn: 281191
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-064-4151/+3792
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Delete Host/windows/win32.hZachary Turner2016-08-091-1/+1
| | | | | | | | | | | | | | | | | | | It's always hard to remember when to include this file, and when you do include it it's hard to remember what preprocessor check it needs to be behind, and then you further have to remember whether it's windows.h or win32.h which you need to include. This patch changes the name to PosixApi.h, which is more appropriately named, and makes it independent of any preprocessor setting. There's still the issue of people not knowing when to include this, because there's not a well-defined set of things it exposes other than "whatever is missing on Windows", but at least this should make it less painful to fix when problems arise. This patch depends on LLVM revision r278170. llvm-svn: 278177
* Add/fix support for i386 elf core filesDimitar Vlahovski2016-07-291-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There were places in the code, assuming(hardcoding) offsets and types that were only valid for the x86_64 elf core file format. The NT_PRSTATUS and NT_PRPSINFO structures are with the 64 bit layout. I have reused them and parse i386 files manually, and fill them in the same struct. Also added some error handling during parsing that checks if the available bytes in the buffer are enough to fill the structures. The i386 core file test case now passes. For reference on the structures layout, I generally used the source of binutils (bfd, readelf) Bug: https://llvm.org/bugs/show_bug.cgi?id=26947 Reviewers: labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D22917 llvm-svn: 277140
* Fix a crash when an ELF section symbol have no nameTamas Berghammer2016-07-221-2/+4
| | | | llvm-svn: 276403
* Typo corrections identified by codespellEd Maste2016-07-191-1/+1
| | | | | | | | | Submitted by giffunip@yahoo.com; I fixed a couple of nearby errors and incorrect changes in the patch. llvm.org/pr27634 llvm-svn: 275983
* Add oat symbolization support for odex filesTamas Berghammer2016-07-061-4/+5
| | | | | | Differential revision: http://reviews.llvm.org/D22040 llvm-svn: 274635
* Ignore oatdata and oatexec symbols more widelyTamas Berghammer2016-07-041-4/+4
| | | | | | | | | | | These are artifical symbols inside android oat files without any value for the user while causing a significant perfoamce hit inside the unwinder. We were already ignoring it inside system@framework@boot.oat bot they have to be ignored in every oat file. Considering that oat files are only used on android this have no effect on any other platfrom. llvm-svn: 274500
* Since our expression parser needs to locate areas of memory that are not in ↵Greg Clayton2016-06-091-0/+4
| | | | | | | | use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
* [LLDB][MIPS] Fix floating point handling in case of thread step-outSagar Thakur2016-05-241-2/+34
| | | | | | | | | | | Patch by Nitesh Jain. Summary: These patch fix thread step-out for hard and soft float. Reviewers: jaydeep, bhushan, clayborg Differential Revision: http://reviews.llvm.org/D20416 llvm-svn: 270564
* Revert rL270207: "[LLDB][MIPS] Fix floating point handling in case of thread ↵Tamas Berghammer2016-05-201-34/+2
| | | | | | | | | | step-out" The CL causes a build breakage on platforms where sizeof(double) == sizeof(long double) and it incorrectly assumes that sizeof(double) and sizeof(long double) is the same on the host and the target. llvm-svn: 270214
* [LLDB][MIPS] Fix floating point handling in case of thread step-outSagar Thakur2016-05-201-2/+34
| | | | | | | | | | | Patch by Nitesh Jain. Summary: These patch fix thread step-out for hard and soft float. Reviewers: clayborg, bhushan, jaydeep Subscribers: mohit.bhakkad, sagar, sdardis Differential: D20416 llvm-svn: 270207
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-181-2/+2
| | | | | | | | | | This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
* [LLDB][MIPS] Setting appropriate ArchSpec::m_flags based on ABISagar Thakur2016-05-111-8/+21
| | | | | | | | | | | 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
* rL267291: Architecture change to thumb on parsing arm.attributes causes ↵Omair Javaid2016-04-261-13/+0
| | | | | | | | | | 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
* Fix ARM attribute parsing for Android after rL267291Tamas Berghammer2016-04-251-6/+3
| | | | | | Differential revision: http://reviews.llvm.org/D19480 llvm-svn: 267422
* Handle invalid values of PLT entry size generated by linkerOmair Javaid2016-04-251-1/+4
| | | | | | | | 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
* Fix unwind failures when PC points beyond the end of a functionUlrich Weigand2016-04-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* ObjectFile: parse EABI AttributesSaleem Abdulrasool2016-04-232-0/+104
| | | | | | | | 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
* Find .plt section in object files generated by recent ldUlrich Weigand2016-04-141-5/+5
| | | | | | | | | | | | | | | | | | | | 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
* Support Linux on SystemZ as platformUlrich Weigand2016-04-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement `target modules dump objfile`Adrian McCarthy2016-04-041-0/+16
| | | | | | Differential Revision: http://reviews.llvm.org/D18464 llvm-svn: 265349
* Allow any build-id length between 4 and 20 bytes inclusiveEd Maste2016-03-141-2/+3
| | | | | | | | | | | | 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
* Add support for handling absolute symbols in ELFTamas Berghammer2016-02-251-24/+44
| | | | | | | | | | | | | | | 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
* Improve the handling of missing elf symtab and missing symbol sizesTamas Berghammer2016-02-182-49/+65
| | | | | | | | | | | | | | | * Generate artificial symbol names from eh_fame during symbol parsing so these symbols are already present when we calcualte the size of the symbols where 0 is specified. * Fix symbol size calculation for the last symbol in the file where it have to last until the end of the parent section. This is the re-commit of the original change after fixing some test failures on OSX. Differential revision: http://reviews.llvm.org/D16996 llvm-svn: 261205
* Revert "Improve the handling of missing elf symtab and missing symbol sizes"Tamas Berghammer2016-02-102-65/+49
| | | | | | | | This reverts commit 252dda67782f2cbf838e375bce21ed4191f6d9ce. The commit caused several test failure on the OSX build bot. llvm-svn: 260377
* Improve the handling of missing elf symtab and missing symbol sizesTamas Berghammer2016-02-102-49/+65
| | | | | | | | | | | | * Generate artificial symbol names from eh_fame during symbol parsing so these symbols are already present when we calcualte the size of the symbols where 0 is specified. * Fix symbol size calculation for the last symbol in the file where it have to last until the end of the parent section. Differential revision: http://reviews.llvm.org/D16996 llvm-svn: 260369
* Add support to detect arm hard float ABI based binaries for ABISysV_armOmair Javaid2016-02-051-0/+9
| | | | | | | | This patch adds logic to detect if underlying binary is using arm hard float abi and use that information while handling return values in ABISysV_arm. Differential revision: http://reviews.llvm.org/D16627 llvm-svn: 259885
* Remove autoconf support from source directories.Eugene Zelenko2016-01-281-14/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
OpenPOWER on IntegriCloud