summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/lang/c
Commit message (Collapse)AuthorAgeFilesLines
* Fix TestRegisterVariables for linux arm/arm64 gcc ver > 5Omair Javaid2017-01-131-1/+1
| | | | | | | | | We are going to turn off buffer overflow introduced by gcc by turning off FORTIFY_SOURCE. Differential revision: https://reviews.llvm.org/D28666 llvm-svn: 291949
* XFAIL TestRegisterVariables on gcc-4.8-x86_64Pavel Labath2017-01-101-0/+2
| | | | | | | I have previously enabled this test for this configuration. However, it turns out it only passes for gcc-4.9. llvm-svn: 291563
* Enable TestBitfields on linux with clangPavel Labath2016-11-241-7/+0
| | | | | | The test has been passing for a while now. llvm-svn: 287884
* Enable TestRegisterVariables for some configurationsPavel Labath2016-11-241-5/+2
| | | | | | It consistently passes for linux-clang-i386, and linux-gcc-x86_64. llvm-svn: 287883
* Un-XFail test on Windows. Has been in "unexpected success" mode for a while.Adrian McCarthy2016-11-101-2/+0
| | | | llvm-svn: 286476
* Added a decorator for the macOS version and switched over testcases that ↵Sean Callanan2016-10-201-3/+1
| | | | | | used platform.release llvm-svn: 284674
* Remove a debug print statement.Jim Ingham2016-10-181-1/+0
| | | | llvm-svn: 284448
* Added a radar on our end for this test's failure.Jim Ingham2016-10-111-1/+1
| | | | llvm-svn: 283956
* Add some logging when trace is on. We're getting a bot failure on i386 that ↵Jim Ingham2016-09-291-8/+15
| | | | | | | | doesn't I can't reproduce locally. Hopefully this will help us catch the reason. llvm-svn: 282810
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-0623-534/+909
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Don't crash when trying to capture persistent variables in a block.Sean Callanan2016-08-261-1/+3
| | | | | | | | | Reports an error instead. We can fix this later to make persistent variables work, but right now we hit an LLVM assertion if we get this wrong. <rdar://problem/27770298> llvm-svn: 279850
* Join TestTlsGlobal tests again and use the proper decoratorPavel Labath2016-07-041-12/+2
| | | | llvm-svn: 274490
* Fixed thread local storage test case to run normally with no expected fail ↵Greg Clayton2016-07-011-2/+12
| | | | | | for Darwin, always skip on windows, and expected fail for all other OSs while mentioning the new bug I filed to track fixing TLS variables: https://llvm.org/bugs/show_bug.cgi?id=28392 llvm-svn: 274393
* Thread local storage was already broken on Linux and the tests were passing ↵Greg Clayton2016-07-011-0/+1
| | | | | | | | | | | because there was a dectorator: @unittest2.expectedFailure("rdar://7796742") Which was covering up the fact this was failing on linux and hexagon. I added back a decorator so we don't break any build bots. llvm-svn: 274388
* Added support for thread local variables on all Apple OS variants.Greg Clayton2016-07-013-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We had support that assumed that thread local data for a variable could be determined solely from the module in which the variable exists. While this work for linux, it doesn't work for Apple OSs. The DWARF for thread local variables consists of location opcodes that do something like: DW_OP_const8u (x) DW_OP_form_tls_address or DW_OP_const8u (x) DW_OP_GNU_push_tls_address The "x" is allowed to be anything that is needed to determine the location of the variable. For Linux "x" is the offset within the TLS data for a given executable (ModuleSP in LLDB). For Apple OS variants, it is the file address of the data structure that contains a pthread key that can be used with pthread_getspecific() and the offset needed. This fix passes the "x" along to the thread: virtual lldb::addr_t lldb_private::Thread::GetThreadLocalData(const lldb::ModuleSP module, lldb::addr_t tls_file_addr); Then this is passed along to the DynamicLoader::GetThreadLocalData(): virtual lldb::addr_t lldb_private::DynamicLoader::GetThreadLocalData(const lldb::ModuleSP module, const lldb::ThreadSP thread, lldb::addr_t tls_file_addr); This allows each DynamicLoader plug-in do the right thing for the current OS. The DynamicLoaderMacOSXDYLD was modified to be able to grab the pthread key from the data structure that is in memory and call "void *pthread_getspecific(pthread_key_t key)" to get the value of the thread local storage and it caches it per thread since it never changes. I had to update the test case to access the thread local data before trying to print it as on Apple OS variants, thread locals are not available unless they have been accessed at least one by the current thread. I also added a new lldb::ValueType named "eValueTypeVariableThreadLocal" so that we can ask SBValue objects for their ValueType and be able to tell when we have a thread local variable. <rdar://problem/23308080> llvm-svn: 274366
* XFAIL tests which fail with gcc on linuxPavel Labath2016-06-291-1/+1
| | | | llvm-svn: 274116
* Enable some tests on linuxPavel Labath2016-06-093-4/+2
| | | | | | | | | This enables a couple of tests which have been shown to run reliably on the linux x86 buildbot. If you see a failure after this commit, feel free to add the xfail back, but please make it as specific as possible (i.e., try to make it not cover i386/x86_64 with clang-3.5, clang-3.9 or gcc-4.9). llvm-svn: 272326
* Revert "Make lldbinline.py regenerate the Makefile each time it builds."Pavel Labath2016-06-071-9/+0
| | | | | | This reverts commit r272024 as it is not windows-compatible. llvm-svn: 272062
* Make lldbinline.py regenerate the Makefile each time it builds.Sean Callanan2016-06-071-0/+9
| | | | | | | | | | | | | If a lldbinline test's source file changed language, then the Makefile wasn't updated. This was a problem if the Makefile was checked into the repository. Now lldbinline.py always regenerates the Makefile and asserts if the newly-generated version is not the same as the one already there. This ensures that the repository will never be out of date without a buildbot failing. http://reviews.llvm.org/D21032 llvm-svn: 272024
* Add "-gmodules" support to the test suite.Todd Fiala2016-05-261-1/+1
| | | | | | | | | | | | | | This change adds the capability of building test inferiors with the -gmodules flag to enable module debug info support. Windows is excluded per @zturner. Reviewers: granata.enrico, aprantl, zturner, labath Subscribers: zturner, labath, lldb-commits Differential Revision: http://reviews.llvm.org/D19998 llvm-svn: 270848
* Mark some aarch64-linux specific xfails marking bug entriesOmair Javaid2016-05-251-0/+1
| | | | | | | | TestBSDArchives.py and TestWatchLocation.py fail due to unicode error and bug has already been reported for arm and macOSx. TestConstVariables.py fails because lldb cant figure out frame variable type when used in expr. llvm-svn: 270780
* xfail TestRedefinitionsInline with older ClangEd Maste2016-05-241-1/+2
| | | | | | | | This fails on FreeBSD 10 with the system compiler, Clang 3.4.1. llvm.org/pr27845 llvm-svn: 270603
* Make sure TestRedefinitionsInInlines.py actually inlines.Chaoren Lin2016-05-231-2/+2
| | | | | | | | | | Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20540 llvm-svn: 270493
* xfail TestRedefinitionsInline on Windows.Zachary Turner2016-05-231-1/+1
| | | | llvm-svn: 270490
* Removed the m_decl_objects map from ClangASTContext.Sean Callanan2016-05-232-0/+23
| | | | | | | | | | | | | m_decl_objects is problematic because it assumes that each VarDecl has a unique variable associated with it. This is not the case in inline contexts. Also the information in this map can be reconstructed very easily without maintaining the map. The rest of the testsuite passes with this cange, and I've added a testcase covering the inline contexts affected by this. <rdar://problem/26278502> llvm-svn: 270474
* Fixed and re-enabled the Clang modules testcase.Sean Callanan2016-05-161-3/+2
| | | | | | | Macros work again after Clang r269554. This testcase just needed some small tweaks to get it going again. llvm-svn: 269704
* Clean up test results on Windows.Zachary Turner2016-05-131-1/+0
| | | | | | | | | Remove XFAIL from some tests that now pass. Add XFAIL to some tests that now fail. Fix a crasher where a null pointer check isn't guarded. Properly handle all types of errors in SymbolFilePDB. llvm-svn: 269454
* Downgrade skip to xfail in TestBitfields on linuxPavel Labath2016-05-051-1/+1
| | | | | | | the test should no longer crash, but we need to investigate why ToT clang still generates debug info we don't understand. llvm-svn: 268619
* Fix syntax errors in TestEnumTypesPavel Labath2016-05-051-1/+2
| | | | llvm-svn: 268616
* XFail TestEnumTypes.py on WindowsAdrian McCarthy2016-05-042-7/+8
| | | | | | Differential Revision: http://reviews.llvm.org/D19943 llvm-svn: 268574
* Import block pointers from DWARF as Clang block pointers, not as structs.Sean Callanan2016-05-021-1/+0
| | | | | | | | | Also added a data formatter that presents them as structs if you use frame variable to look at their contents. Now the blocks testcase works. <rdar://problem/15984431> llvm-svn: 268307
* Fix TestEnumTypes.py for 32 bit platforms.Chaoren Lin2016-04-291-2/+2
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D19751 llvm-svn: 268135
* Watch out for compilers that generate bad bitfield info. If the bit size of ↵Greg Clayton2016-04-291-1/+0
| | | | | | | | | a bitfield member doesn't lie within the bit bounds of the type itself, just leave it out so we don't get clang asserting and killing our IDE when it gets unhappy with the information. https://llvm.org/bugs/show_bug.cgi?id=27515 <rdar://problem/21082998> llvm-svn: 268110
* Make sure LLDB can deal with forward declarations to enums without crashing ↵Greg Clayton2016-04-292-1/+19
| | | | | | | | or asserting. <rdar://problem/23776428> llvm-svn: 268098
* XFail TestBitfields.py Python API tests.Chaoren Lin2016-04-281-0/+1
| | | | | | | | | | | | | | Summary: Started failing after rL267895. Possibly related to http://llvm.org/pr27510. Reviewers: labath, tfiala Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D19680 llvm-svn: 267923
* Fix TestRegisterVariables.py on WindowsAdrian McCarthy2016-04-261-3/+3
| | | | | | | | Use __attribute__((regparm(x))) to ensure the compiler enregisters at least some arguments when calling functions. Differential Revision: http://reviews.llvm.org/D19548 llvm-svn: 267616
* skip TestBitfields.py on OS XTodd Fiala2016-04-251-0/+1
| | | | | | | tracked by: https://llvm.org/bugs/show_bug.cgi?id=27515 llvm-svn: 267421
* Skip TestBitfileds on linuxPavel Labath2016-04-251-0/+1
| | | | | | | Test added in r267248 exposed a bug in handling of dwarf produced by clang>=3.9, which causes a crash during expression evaluation. Skip the test until this is sorted out. llvm-svn: 267407
* DWARF layout for bitfields is wrong when the bit offset is negative. Greg Clayton2016-04-222-0/+22
| | | | | | | | Some older versions of clang emitted bit offsets that were negative and these bitfields would have their bitfield-ness stripped off and it would cause a clang assertion in clang assertions were enabled. I updated the bitfield C test to make sure we don't regress. <rdar://problem/21082998> llvm-svn: 267248
* 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 a block in the expression parser.Sean Callanan2016-04-151-3/+13
| | | | | | <rdar://problem/25738696> llvm-svn: 266389
* Fix and xfail TestRegisterVariables after rL265498Tamas Berghammer2016-04-062-8/+3
| | | | llvm-svn: 265527
* make TestRegisterVariables slightly more resilientTodd Fiala2016-04-062-16/+123
| | | | | | | | | | | | | | | | | | | This test sets the compiler optimization level to -O1 and makes some assumptions about how local frame vars will be stored (i.e. in registers). These assumptions are not always true. I did a first-pass set of improvements that: (1) no longer assumes that every one of the target locations has every variable in a register. Sometimes the compiler is even smarter and skips the register entirely. (2) simply expects one of the 5 or so variables it checks to be in a register. This test probably passes on a whole lot more systems than it used to now. This is certainly true on OS X. llvm-svn: 265498
* Enable expectedFailure for all Clang versions in TestRegisterVariablesEd Maste2016-03-141-1/+1
| | | | | | | | | | In r262970 this was changed from xfail Clang < 3.5 to > 3.5, but it still fails on FreeBSD 10's system Clang 3.4.1 so assume it fails on all versions. llvm.org/pr26937 llvm-svn: 263467
* Fixed ValueObject::GetExpressionPath() for paths including anonymous ↵Marianne Mailhot-Sarrasin2016-03-101-0/+11
| | | | | | | | | | 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
* [DWARFASTParserClang] Start with member offset of 0 for members of union types.Siva Chandra2016-03-103-0/+69
| | | | | | | | | | | | | | | Summary: GCC does not emit DW_AT_data_member_location for members of a union. Starting with a 0 value for member locations helps is reading union types in such cases. Reviewers: clayborg Subscribers: ldrumm, lldb-commits Differential Revision: http://reviews.llvm.org/D18008 llvm-svn: 263085
* [TestRegisterVariables] Adjust compiler range in expected failure decorator.Siva Chandra2016-03-091-2/+2
| | | | | | | | Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17972 llvm-svn: 262970
* Support floating point values in 128-bit SSE vector registersAdrian Prantl2016-03-082-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | 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 TestInlines.py on WindowsAdrian McCarthy2016-02-294-114/+0
| | | | | | | | | | | | | | The inlining semantics for C and C++ are different, which affects the test's expectation of the number of times the function should appear in the binary. In the case of this test, C semantics means there should be three instances of inner_inline, while C++ semantics means there should be only two. On Windows, clang uses C++ inline semantics even for C code, and there doesn't seem to be a combination of compiler flags to avoid this. So, for consistency, I've recast the test to use C++ everywhere. Since the test resided under lang/c, it seemed appropriate to move it to lang/cpp. This does not address the other XFAIL for this test on Linux/gcc. See https://llvm.org/bugs/show_bug.cgi?id=26710 Differential Revision: http://reviews.llvm.org/D17650 llvm-svn: 262255
* Add the "block" keyword to "thread step-in -e", and an alias that uses it: ↵Jim Ingham2016-02-263-0/+158
| | | | | | | | | "sif <target function>" - i.e. step-into-function to allow you to step through a complex calling sequence into a particular function that may span multiple lines. Also some test cases for this and the --step-target feature. llvm-svn: 261953
OpenPOWER on IntegriCloud