summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert r266311 - Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-141-250/+265
| | | | | | Try to get 32-bit build bots running again. llvm-svn: 266341
* Handle bit fields on big-endian systems correctlyUlrich Weigand2016-04-142-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-141-265/+250
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make Scalar::GetBytes and RegisterValue::GetBytes constUlrich Weigand2016-04-142-177/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* Remove unintentional returnBhushan D. Attarde2016-04-111-1/+0
| | | | llvm-svn: 265931
* Print environment when dumping arch tripleStephane Sezer2016-04-051-0/+4
| | | | | | | | | | | | | | 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
* Consolidate the knowledge of what arm cores are always executingJason Molenda2016-04-052-4/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Get rid of a global constructor that was causing a warning on MacOSX and ↵Greg Clayton2016-03-241-3/+14
| | | | | | make the Timer safe to use after the main threads global destructor chain is called. llvm-svn: 264346
* Fix for missing prompt on WindowsTed Woodward2016-03-241-0/+23
| | | | | | | | | | | | 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
* Unicode support on Win32.Zachary Turner2016-03-222-15/+17
| | | | | | | | | | | | | 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
* Remove unnecessary <limits> includes.Jim Ingham2016-03-156-7/+0
| | | | llvm-svn: 263588
* Shuffle an #undef to avoid a warning on FreeBSDEd Maste2016-03-141-2/+1
| | | | | | | | | | 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
* Let's not convert from UINT32_MAX to the std::numeric_limits version.Jim Ingham2016-03-124-22/+24
| | | | llvm-svn: 263333
* Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; ↵Eugene Zelenko2016-03-124-420/+161
| | | | | | other minor fixes. llvm-svn: 263312
* Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; ↵Eugene Zelenko2016-03-113-293/+199
| | | | | | other minor fixes. llvm-svn: 263300
* Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; ↵Eugene Zelenko2016-03-113-318/+253
| | | | | | other minor fixes. llvm-svn: 263289
* Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; ↵Eugene Zelenko2016-03-106-273/+184
| | | | | | other minor fixes. llvm-svn: 263174
* Fixed ValueObject::GetExpressionPath() for paths including anonymous ↵Marianne Mailhot-Sarrasin2016-03-101-1/+1
| | | | | | | | | | 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
* Certain hardware architectures have registers of 256 bits in sizeEnrico Granata2016-03-103-28/+424
| | | | | | 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
* Add an "offset" option to "break set -n" and "break set -f -l". Jim Ingham2016-03-091-0/+2
| | | | | | | | | | | | 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
* Support floating point values in 128-bit SSE vector registersAdrian Prantl2016-03-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix log in Broadcaster causing a crashTamas Berghammer2016-03-081-5/+4
| | | | llvm-svn: 262925
* Change over the broadcaster/listener process to hold shared or weak pointersJim Ingham2016-03-076-141/+229
| | | | | | | | | | | | | | 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
* Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; ↵Eugene Zelenko2016-03-036-312/+237
| | | | | | other minor fixes. llvm-svn: 262570
* Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; ↵Eugene Zelenko2016-03-022-220/+196
| | | | | | other minor fixes. llvm-svn: 262450
* Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; ↵Eugene Zelenko2016-03-027-277/+226
| | | | | | other minor fixes. llvm-svn: 262441
* Add an LLDB data formatter for single-element NSArray and NSDictionary Cocoa ↵Enrico Granata2016-02-295-12/+34
| | | | | | | | containers Fixes rdar://23715118 llvm-svn: 262254
* Add support for DW_OP_push_object_address in dwarf expressionsTamas Berghammer2016-02-261-1/+9
| | | | | | | | | Additionally fix the type of some dwarf expression where we had a confusion between scalar and load address types after a dereference. Differential revision: http://reviews.llvm.org/D17604 llvm-svn: 262014
* Fix all of the unannotated switch cases to annotate the fall through or do ↵Greg Clayton2016-02-265-8/+15
| | | | | | the right thing and break. llvm-svn: 261950
* Handle the case when a variable is only valid in part of the enclosing scopeTamas Berghammer2016-02-251-3/+4
| | | | | | | | | | | DWARF stores this information in the DW_AT_start_scope attribute. This CL add support for this attribute and also changes the functions displaying frame variables to only display the variables currently in scope. Differential revision: http://reviews.llvm.org/D17449 llvm-svn: 261858
* Some fixes for case insensitive paths on Windows.Zachary Turner2016-02-242-3/+29
| | | | | | | | | | | | | | | | | | | Paths on Windows are not case-sensitive. Because of this, if a file is called main.cpp, you should be able to set a breakpoint on it by using the name Main.cpp. In an ideal world, you could just tell people to match the case, but in practice this can be a real problem as it requires you to know whether the person who compiled the program ran "clang++ main.cpp" or "clang++ Main.cpp", both of which would work, regardless of what the file was actually called. This fixes http://llvm.org/pr22667 Patch by Petr Hons Differential Revision: http://reviews.llvm.org/D17492 Reviewed by: zturner llvm-svn: 261771
* [LLDB][MIPS] Provide CPU string to compiler for appropriate code generation ↵Bhushan D. Attarde2016-02-181-0/+50
| | | | | | | | | | | | | | | for MIPS SUMMARY: This patch implements ArchSpec::GetClangTargetCPU() that provides string representing current architecture as a target CPU. This string is then passed to tools like clang so that they generate correct code for that target. Reviewers: clayborg, zturner Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits Differential Revision: http://reviews.llvm.org/D17022 llvm-svn: 261206
* Add -Wimplicit-fallthrough command line option to clang inJason Molenda2016-02-167-10/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | the xcode project file to catch switch statements that have a case that falls through unintentionally. Define LLVM_FALLTHROUGH to indicate instances where a case has code and intends to fall through. This should be in llvm/Support/Compiler.h; Peter Collingbourne originally checked in there (r237766), then reverted (r237941) because he didn't have time to mark up all the 'case' statements that were intended to fall through. I put together a patch to get this back in llvm http://reviews.llvm.org/D17063 but it hasn't been approved in the past week. I added a new lldb-private-defines.h to hold the definition for now. Every place in lldb where there is a comment that the fall-through is intentional, I added LLVM_FALLTHROUGH to silence the warning. I haven't tried to identify whether the fallthrough is a bug or not in the other places. I haven't tried to add this to the cmake option build flags. This warning will only work for clang. This build cleanly (with some new warnings) on macosx with clang under xcodebuild, but if this causes problems for people on other configurations, I'll back it out. llvm-svn: 260930
* Now that SymbolFileDWARF supports having types in completely separate .pcm ↵Greg Clayton2016-02-102-9/+14
| | | | | | | | | | | | | | file with "-fmodules -gmodules", each SymbolFileDWARF can reference module DWARF info by looking in other DWARF files. Then if you have 1000 .o files that each reference one or more .pcm files in their debug info, a simple Module::FindTypes(...) call can end up searching the same .pcm file over and over and over. Now all internal FindTypes methods in classes (ModuleList, Module, SymbolFile) now take an extra argument: llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files Each time a SymbolFile::FindTypes() is called, it needs to check the searched_symbol_files list to make sure it hasn't already been asked to find the type and return immediately if it has been checked. This will stop circular dependencies from also crashing LLDB during type queries. This has proven to be an issue when debugging large applications on MacOSX that use DWARF in .o files. <rdar://problem/24581488> llvm-svn: 260434
* Fix invalid shift operator overload in ScalarPavel Labath2016-02-091-1/+1
| | | | | | | | | | | | | | Summary: This also fixes an infinite recursion between lldb_private::operator>> () and Scalar::operator>>= (). Reviewers: sagar, tberghammer, labath Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D16868 Patch by Marianne Mailhot-Sarrasin llvm-svn: 260239
* Remove Timer::Initialize routinePavel Labath2016-02-011-23/+12
| | | | | | | | | | | | | | | | | | | | Summary: I've run into an issue when running unit tests, where the underlying problem turned out to be that we were creating Timer objects (through several layers of indirection) without calling Timer::Initialize. Since Timer's thread-local storage was not properly initialized, we were overwriting gtest's own thread-local storage, causing test failures. Instead of requiring that every test calls Timer::Initialize(), I remove the function altogether: The thread-local storage can be initialized on-demand, and the g_file variable initialized to stdout and never changed, so I have simply removed it. Reviewers: clayborg, zturner, tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D16722 llvm-svn: 259356
* Fixed a couple of places where we were getting the module from aJim Ingham2016-01-291-1/+5
| | | | | | | section and using it w/o checking that it was valid. This can cause crashes - usually when tearing down a target. llvm-svn: 259237
* Remove autoconf support from source directories.Eugene Zelenko2016-01-281-14/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
* Set symbol types for function symbols loaded from PE/COFFAdrian McCarthy2016-01-261-8/+10
| | | | | | | | | | | | | | | | This fixes the regression of several tests on Windows after rL258621. The root problem is that ObjectFilePECOFF was not setting type information for the symbols, and the new CL rejects symbols without type information, breaking functionality like thread step-over. The fix sets the type information for functions (and creates a TODO for other types). Along the way, I fixed some typos and formatting that made the code I was debugging harder to understand. In the long run, we should consider replacing most of ObjectFilePECOFF with the COFF parsing code from LLVM. Differential Revision: http://reviews.llvm.org/D16563 llvm-svn: 258758
* [LLDB] Consider only valid symbols while resolving by addressMohit K. Bhakkad2016-01-231-1/+10
| | | | | | | | Reviewers: clayborg. Subscribers: jaydeep, bhushan, sagar, nitesh.jain, lldb-commits. Differential Revision: http://reviews.llvm.org/D16397 llvm-svn: 258621
* Remove duplicate header added in r256927Ewan Crawford2016-01-071-1/+0
| | | | | | | | | r256927 included a duplicate StreamString header file. This patch simply removes the duplicate. Author: Luke Drummond <luke.drummond@codeplay.com> Differential Revision: http://reviews.llvm.org/D15948 llvm-svn: 257061
* Add LogDump methods to lldb_private::StringList.Ewan Crawford2016-01-061-0/+37
| | | | | | | | | This patch eases the printing of iterable string containers. Author: Luke Drummond <luke.drummond@codeplay.com> Differential Revision: http://reviews.llvm.org/D15773 llvm-svn: 256927
* No need for a custom function here; just use what C providesEnrico Granata2015-12-221-29/+1
| | | | llvm-svn: 256223
* Reduce code duplicationEnrico Granata2015-12-211-64/+16
| | | | llvm-svn: 256212
* Inspect DW_AT_const_value global static const variablesEwan Crawford2015-12-171-0/+1
| | | | | | | | | | | | This patch adds support for printing global static const variables which are given a DW_AT_const_value DWARF tag by clang. Fix for bug https://llvm.org/bugs/show_bug.cgi?id=25653 Reviewers: clayborg, tberghammer Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D15576 llvm-svn: 255887
* Don't demangle a name when Mangled::GetName() is called with ePreferMangled. ↵Greg Clayton2015-12-171-6/+4
| | | | | | Only demangle if this isn't the the value for the "preference" argument indicating the user wants the demangled name. This will stop a lot of symbols from being demangled when parsing the symbol table in ObjectFileMachO. llvm-svn: 255864
* Rework breakpoint language filtering to use the symbol context's language.Dawn Perchik2015-12-161-2/+14
| | | | | | | | | | | | | | | | This patch reworks the breakpoint filter-by-language patch to use the symbol context instead of trying to guess the language solely from the symbol's name. This has the advantage that symbols compiled with debug info will have their actual language known. Symbols without debug info will still do the same "guess"ing because Symbol::GetLanguage() is implemented using Mangled::GuessLanguage(). The recognition of ObjC names was merged into Mangled::GuessLanguage. Reviewed by: jingham, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D15326 llvm-svn: 255808
* Differential Revision: http://reviews.llvm.org/D15333Aidan Dodds2015-12-101-9/+7
| | | | llvm-svn: 255237
* Fix typo in a commentKamil Rytarowski2015-12-041-1/+1
| | | | llvm-svn: 254768
OpenPOWER on IntegriCloud