summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
...
* Removed extraneous print() in decorator for enabling module debuggingKate Stone2016-04-201-1/+0
| | | | llvm-svn: 266924
* When making an array or stuct/union/class elements, make sure the type is ↵Greg Clayton2016-04-201-1/+28
| | | | | | | | 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
* update Jenkins Xcode buildbot target for r266885Todd Fiala2016-04-201-1/+1
| | | | llvm-svn: 266917
* Fix a bug where LLDB would crash if 'apropos <anything>' was used after ↵Enrico Granata2016-04-208-1/+87
| | | | | | spawning an inferior process llvm-svn: 266911
* Add missing file needed for PDB unittests.Zachary Turner2016-04-201-0/+0
| | | | llvm-svn: 266886
* test infra: move test event-related handling into its own packageTodd Fiala2016-04-2014-674/+734
| | | | | | | | | | | | | | | | | | | | | | | This change moves all the test event handling and its related ResultsFormatter classes out of the packages/Python/lldbsuite/test dir into a packages/Python/lldbsuite/test_event package. Formatters are moved into a sub-package under that. I am limiting the scope of this change to just the motion and a few minor issues caught by a static Python checker (e.g. removing unused import statements). This is a pre-step for adding package-level tests to the test event system. I also intend to simplify test event results formatter selection after I make sure this doesn't break anybody. See: http://reviews.llvm.org/D19288 Reviewed by: Pavel Labath llvm-svn: 266885
* Fix xfail for test_tilde_home_directory on windowsTamas Berghammer2016-04-201-1/+1
| | | | llvm-svn: 266867
* llvm::sys::path::home_directory() relies on having "HOME" set in the ↵Greg Clayton2016-04-192-1/+75
| | | | | | | | | | 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
* Eliminate circular dependency introduced between lldbtest.py and decorators.pyKate Stone2016-04-191-3/+2
| | | | llvm-svn: 266815
* Adds a test to detect when clang omits specialized generic types from debug ↵Kate Stone2016-04-196-0/+118
| | | | | | information when using precompiled headers and -gmodules. llvm-svn: 266791
* Revert "LLDB: Fixed two race conditions when stopping private state thread"Pavel Labath2016-04-192-8/+9
| | | | | | This reverts commit r266733 as it causes a number of failures on linux buildbots. llvm-svn: 266736
* LLDB: Fixed two race conditions when stopping private state threadMarianne Mailhot-Sarrasin2016-04-192-9/+8
| | | | | | | | | | | | | | 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
* Fix typo in TestSourceManager.pyPavel Labath2016-04-191-1/+1
| | | | llvm-svn: 266725
* test infra cleanup: convert test_runner lib into packageTodd Fiala2016-04-196-30/+19
| | | | | | | | | | | | | | | | | | | | | Also does the following: * adopts PEP8 naming convention for OptionalWith class (now optional_with). * moves test_runner/lldb_utils.py to lldbsuite/support/optional_with.py. * packages tests in a subpackage of test_runner per recommendations in http://the-hitchhikers-guide-to-packaging.readthedocs.org/en/latest/creation.html Tests can be run from within pacakges/Python/lldbsuite/test via this command: python -m unittest discover test_runner The primary cleanup this allows is avoiding the need to muck with the PYTHONPATH variable from within the source files. This also aids some of the static code checkers as they don't need to run code to determine the proper python path. llvm-svn: 266710
* Fix Windows build.Chaoren Lin2016-04-191-0/+1
| | | | llvm-svn: 266702
* ensure lldbinline remembers .py extensionTodd Fiala2016-04-182-6/+20
| | | | | | | | | | | | | | | | | | This ensure lldbinline.test_file paths are tracked as .py files rather than .pyc files. Also, this change adds an assert to the test infrastructure if a filename that is not ending in .py is attempted to be added to the test events infrastructure where we track test results. See: http://reviews.llvm.org/D19215 Earlier revision reviewed by: Pavel Labath llvm-svn: 266664
* fix a race is the LLDB test suite results collectionTodd Fiala2016-04-184-6/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The race boiled down to this: If a test worker queue is able to run the test inferior and clean up before the dosep.py listener socket is spun up, and the worker queue is the last one (as would be the case when there's only one test rerunning in the rerun queue), then the test suite will exit the main loop before having a chance to process any test events coming from the test inferior or the worker queue job control. I found this race to be far more likely on fast hardware. Our Linux CI is one such example. While it will show up primarily during meta test events generated by a worker thread when a test inferior times out or exits with an exceptional exit (e.g. seg fault), it only requires that the OS takes longer to hook up the listener socket than it takes for the final test inferior and worker thread to shut down. See: http://reviews.llvm.org/D19214 reviewed by: Pavel Labath llvm-svn: 266624
* Attempt to fix darwin build after header refactor in llvm (r266595)Pavel Labath2016-04-181-1/+1
| | | | llvm-svn: 266605
* Fixup r266327Pavel Labath2016-04-181-2/+2
| | | | | | Fix XFAILed tests in TestThreadStates for the new signature of wait_for_running_event. llvm-svn: 266598
* [LLDB][MIPS] Fix TestConcurrentEventsMohit K. Bhakkad2016-04-181-35/+35
| | | | | | | | | | Patch by Nitesh Jain Reviewers: clayborg Subscribers: jaydeep, bhushan, mohit.bhakkad, sagar Differential Revision: http://reviews.llvm.org/D18389 llvm-svn: 266589
* Fix cmake build after r266524.Oleksiy Vyalov2016-04-161-0/+1
| | | | llvm-svn: 266530
* Replace hardcoded comment at 'lit.site.cfg.in'Alex Denisov2016-04-162-4/+4
| | | | | | | | | | | | At the moment almost every lit.site.cfg.in contains two lines comment: ## Autogenerated by LLVM/Clang configuration. # Do not edit! The patch adds variable LIT_SITE_CFG_IN_HEADER, that is replaced from configure_lit_site_cfg with the note and some useful information. llvm-svn: 266522
* 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
* Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-157-290/+266
| | | | | | | | | | | | | 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
* Make Scalar::SChar return an explicit signed typeUlrich Weigand2016-04-152-2/+2
| | | | | | | | This is needed for platforms where the default "char" type is unsigned. Originally committed as part of (now reverted) r266311. llvm-svn: 266420
* Fix Scalar::MakeSigned for 128- and 256-bit types.Ulrich Weigand2016-04-151-2/+2
| | | | | | | | Obvious fix for incorrect result types of the operation. Originally committed as part of (now reverted) r266311. llvm-svn: 266419
* Fix Scalar::SetValueFromData for 128- and 256-bit typesUlrich Weigand2016-04-151-16/+16
| | | | | | | | Obvious fix for incorrect use of GetU64 offset pointer. Originally committed as part of (now reverted) r266311. llvm-svn: 266418
* Fix ABISysV_s390x::GetArgumentValuesUlrich Weigand2016-04-151-2/+1
| | | | | | | | 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
* Make destructor breakpoint location test more resilientPavel Labath2016-04-152-8/+43
| | | | | | | | | | | | | | | | | | | | | | Summary: The original breakpoint location test was failing for linux, because the compilers here tend to merge the full-object and subobject destructors even at -O0 (as a result, we are getting only 2 breakpoint locations, and not 4 as the test expected. The fixup in r266164 substantially weakened the test, as it now did not check whether both kinds of destructors were being found. Because of these contraints, I have altered the logic of the test. It sets the breakpoint by name, and then independently verifies that the breakpoint is set on the correct demangled symbol name (which is not very meaningful since both kinds of destructors demangle to the same name) *and* the correct symbol address (which is obtained by looking up the mangled symbol name). Reviewers: clayborg Subscribers: ovyalov, zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D19052 llvm-svn: 266416
* Add the PDBParser.{cpp,h} files to the Xcode project.Jim Ingham2016-04-151-0/+6
| | | | llvm-svn: 266407
* Rename out->std_out in AppleObjCRuntimeV2.cpp.Oleksiy Vyalov2016-04-151-17/+17
| | | | llvm-svn: 266401
* Blocks are only reliably supported on Darwin. Disable the test otherwise.Sean Callanan2016-04-151-0/+3
| | | | llvm-svn: 266400
* Added a testcase for defining and using lambdas in the expression parser.Sean Callanan2016-04-152-0/+21
| | | | | | <rdar://problem/25739133> llvm-svn: 266397
* Initial support for reading type information from PDBs.Zachary Turner2016-04-1511-20/+844
| | | | | | | | | | | | | | | | 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
* Added a testcase for defining and using a block in the expression parser.Sean Callanan2016-04-151-3/+13
| | | | | | <rdar://problem/25738696> llvm-svn: 266389
* Don't disable stdin buffering on WindowsAdrian McCarthy2016-04-141-6/+5
| | | | | | | | Disabling buffering exposes a bug in the MS VS 2015 CRT implementation of fgets, where you sometimes have to hit Enter twice, depending on if the input had an odd or even number of characters. This was hidden until a few days ago by the Python initialization which was re-enabling buffering on the streams. A few days ago, Enrico make the Python initialization on-demand, which exposed this problem. llvm-svn: 266384
* Fix Xcode project after recent s390x changes.Greg Clayton2016-04-141-0/+44
| | | | llvm-svn: 266361
* Fix regression in gnu_libstdcpp.py introduced by r266313Ulrich Weigand2016-04-141-1/+1
| | | | | | CreateChildAtOffset needs a byte offset, not an element number. llvm-svn: 266352
* Disable LinuxCoreTestCase.test_s390xUlrich Weigand2016-04-141-0/+2
| | | | | | | This seems to hang on non-s390x hosts. Disable for now to get the build bots going again. llvm-svn: 266343
* Revert r266311 - Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-147-342/+310
| | | | | | Try to get 32-bit build bots running again. llvm-svn: 266341
* [test] make expect_state_changes actually expect *only* themPavel Labath2016-04-143-13/+15
| | | | | | | | The android dirty stderr problem has uncovered an issue where lldbutil.expect_state_changes was reading events other than state change events, which resulted in general confusion. Make it more strict to accept *only* state changes. llvm-svn: 266327
* [test] Relax stderr expectations on targets with chatty outputPavel Labath2016-04-147-12/+31
| | | | | | | | | | | | | | | Summary: On some android targets, a binary can produce additional garbage (e.g. warning messages from the dynamic linker) on the standard error, which confuses some tests. This relaxes the stderr expectations for targets known for their chattyness. Reviewers: tfiala, ovyalov Subscribers: tberghammer, danalbert, srhines, lldb-commits Differential Revision: http://reviews.llvm.org/D19114 llvm-svn: 266326
* 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
* Fix test cases for big-endian systemsUlrich Weigand2016-04-1410-75/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A number of test cases were failing on big-endian systems simply due to byte order assumptions in the tests themselves, and no underlying bug in LLDB. These two test cases: tools/lldb-server/lldbgdbserverutils.py python_api/process/TestProcessAPI.py actually check for big-endian target byte order, but contain Python errors in the corresponding code paths. These test cases: functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py functionalities/data-formatter/data-formatter-smart-array/TestDataFormatterSmartArray.py functionalities/data-formatter/synthcapping/TestSyntheticCapping.py lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py python_api/sbdata/TestSBData.py (first change) could be fixed to check for big-endian target byte order and update the expected result strings accordingly. For the two synthetic tests, I've also updated the source to make sure the fake_a value is always nonzero on both big- and little-endian platforms. These test case: python_api/sbdata/TestSBData.py (second change) functionalities/memory/cache/TestMemoryCache.py simply accessed memory with the wrong size, which wasn't noticed on LE but fails on BE. Differential Revision: http://reviews.llvm.org/D18985 llvm-svn: 266315
* Fix ARM instruction emulation tests on big-endian systemsUlrich Weigand2016-04-143-62/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Miscellaneous fixes for big-endian systemsUlrich Weigand2016-04-144-9/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Handle bit fields on big-endian systems correctlyUlrich Weigand2016-04-145-10/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-147-310/+342
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-146-194/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fixes for platforms that default to unsigned charUlrich Weigand2016-04-143-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud