Add support in ProcessGDBRemote::GetGDBServerRegisterInfo
for recognizing a generic "arm" architecture that will be used if
nothing better is available so that we don't ignore the register
definitions if we didn't already have an architecture set.
Also in ProcessGDBRemote::DoConnectRemote don't set the target
arch unless we have a valid architecture to set it to.
Platform::ConnectProcess will try to get the current target's
architecture, or the default architecture, when creating the
target for the connection to be attempted. If lldb was started
with a target binary, we want to create this target with that
architecture in case the remote gdb stub doesn't supply a
qHostInfo arch.
Add logging to Target::MergeArchitecture.
<rdar://problem/34916465>
llvm-svn: 345106
Summary: These tests fail on Windows because of known limitations (a.k.a. bugs) with the current implementation of GetFrameAtIndex
Reviewers: asmith, vsk
Reviewed By: vsk
Subscribers: abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D53415
llvm-svn: 344788
Summary: They fail similarly to some of the other breakpoint tests on Windows, so I suspect the cause is the same. I've linked to the same bug.
Reviewers: asmith, zturner, jingham
Subscribers: abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D53331
llvm-svn: 344744
The TestTailCallFrameSBAPI.py test checks that function names in a
backtrace are equal to an expected value.
Use a relaxed substring check because function dislpay names are
platform-dependent. E.g we see "void sink(void)" on Windows, but "sink()" on
Darwin. This seems like a bug -- just work around it for now.
llvm-svn: 344634
Some tests in test/functionalities/tail_call_frames are failing on
non-Darwin platforms. Use assertEqual to improve logging on failure.
llvm-svn: 344581
Summary:
If the names are not unique, the tests overwrite each other's results and logs. This also causes failures on platforms where the files are locked for writing.
The names of the class/test pairs *have to* always be unique. The easiest way to achieve that is to name each class differently (usually the same as the file name).
Reviewers: jasonmolenda, asmith
Subscribers: clayborg, nemanjai, kbarton, lldb-commits
Differential Revision: https://reviews.llvm.org/D53297
llvm-svn: 344547
This patch teaches lldb to detect when there are missing frames in a
backtrace due to a sequence of tail calls, and to fill in the backtrace
with artificial tail call frames when this happens. This is only done
when the execution history can be determined from the call graph and
from the return PC addresses of calls on the stack. Ambiguous sequences
of tail calls (e.g anything involving tail calls and recursion) are
detected and ignored.
Depends on D49887.
Differential Revision: https://reviews.llvm.org/D50478
llvm-svn: 343900
Before inspecting the contents of a list, make sure that we've stepped
past the push_back() that inserts the element we're interested in.
llvm-svn: 343899
This is a follow-up to https://reviews.llvm.org/D46362.
When evaluating a complex expression in DWARFExpression::Evaluate,
file addresses must be resolved to load addresses before we can
perform operations such as DW_OP_deref on them.
For this the address goes through three steps
1. Read the file address as stored in the DWARF
2. Link/relocate the file address (when reading from a .dSYM, this is a no-op)
3. Convert the file address to a load address.
D46362 implemented step (3) by resolving the file address using the
Module that the original DWARF came from. In the case of a dSYM that
is correct, but when reading from .o files, we need to look up
relocated/linked addresses, so the right place to look them up is the
current frame's module. This patch fixes that by setting the
expression's Module to point to the linked debugmap object.
A word a bout the unorthodox testcase: The motivating testcase for
this fix is in Swift, but I managed to hand-modify LLVM-IR for a
trivial C program to exhibit the same problem, so we can fix this in
llvm.org.
rdar://problem/44689915
Differential Revision: https://reviews.llvm.org/D52678
llvm-svn: 343612
max number of stack frames to backtrace, make it a setting,
target.process.thread.max-backtrace-depth.
Add a test case for the setting.
<rdar://problem/28759559>
llvm-svn: 343029
On linux, we do not support automatic loading of dependent modules, so
the module list will always contain just one module (until the target is
launched).
llvm-svn: 343016
When creating a target, lldb loads all dependent files (i.e. libs in
LC_LOAD_DYLIB for Mach-O). This can be confusing, especially when two
versions of the same library end up in the shared cache. It's possible
to change this behavior, by specifying target create -d <target> these
dependents are not loaded.
This patch changes the default behavior to only load dependent files
only when the target is an executable. When creating a target for a
library, it is now no longer necessary to pass -d. The user can still
override this behavior by specifying the -d option to change this
behavior.
rdar://problem/43721382
Differential revision: https://reviews.llvm.org/D51934
llvm-svn: 342634
Add a "filecheck" method to the LLDB test base. This allows test authors
to pattern match command output using FileCheck, making it possible to
write stricter tests than what `self.expect` allows.
For context (motivation, examples of stricter checking, etc), see the
lldb-dev thread: "Using FileCheck in lldb inline tests".
Differential Revision: https://reviews.llvm.org/D50751
llvm-svn: 342508
I started from a clean slate to do the checkin, but forgot to svn add the new files.
Do that now.
Also add the one new source file to CMakeLists.txt
llvm-svn: 342190
Summary:
This patch adds a framework for adding descriptions to the command completions we provide.
It also adds descriptions for completed top-level commands so that we can test this code.
Completions are in general supposed to be displayed alongside the completion itself. The descriptions
can be used to provide additional information about the completion to the user. Examples for descriptions
are function signatures when completing function calls in the expression command or the binary name
when providing completion for a symbol.
There is still some boilerplate code from the old completion API left in LLDB (mostly because the respective
APIs are reused for non-completion related purposes, so the CompletionRequest doesn't make sense to be
used), so that's why I still had to change some function signatures. Also, as the old API only passes around a
list of matches, and the descriptions are for these functions just another list, I had to add some code that
essentially just ensures that both lists are always the same side (e.g. all the manual calls to
`descriptions->AddString(X)` below a `matches->AddString(Y)` call).
The initial command descriptions that come with this patch are just reusing the existing
short help that is already added in LLDB.
An example completion with descriptions looks like this:
```
(lldb) pl
Available completions:
platform -- Commands to manage and create platforms.
plugin -- Commands for managing LLDB plugins.
```
Reviewers: #lldb, jingham
Reviewed By: #lldb, jingham
Subscribers: jingham, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D51175
llvm-svn: 342181
This patch improves the support of DWARF5.
Particularly the reporting of source code locations.
Differential revision: https://reviews.llvm.org/D51935
llvm-svn: 342153
Summary:
The 'memory region' command is at the moment not tested at all by our test suite.
This patch just adds a basic test that at least provides some basic testing.
Reviewers: #lldb, davide
Reviewed By: #lldb, davide
Subscribers: vsk, davide, lldb-commits
Differential Revision: https://reviews.llvm.org/D51930
llvm-svn: 342042
Summary: An address breakpoint of the form "b 0x1000" won't resolve if it's created while the process isn't running. This patch deletes Address::SectionWasDeleted, renames Address::SectionWasDeletedPrivate to SectionWasDeleted (and makes it public), and changes the section check in Breakpoint::ModulesChanged back to its original form
Reviewers: jingham, #lldb
Reviewed By: jingham
Subscribers: davide, lldb-commits
Differential Revision: https://reviews.llvm.org/D51816
llvm-svn: 341849
This patch allows LLDB to print column info in backtraces et al. if
available, which is useful when the backtrace contains a frame like
the following:
f(can_crash(0), can_crash(1));
Differential Revision: https://reviews.llvm.org/D51661
llvm-svn: 341506
This applies the same workaround as r321271 to other tests. The root
problem is that lldb finds an internal symbol with the same name in the
debug info of system libraries, and then fails to disambiguate between
the two.
llvm-svn: 341235
Using a listen queue of length 0 caused a deadlock on my machine in the
gdb-client tests while attempting to establish the loopback socket
connection.
I am not sure if this is down to a different python or kernel version,
but in either case, having queue of length zero sounds like a bad idea,
so I'm bumping that to one (which also fixes the deadlock).
llvm-svn: 341096
Summary:
This patch adds initial code completion support for the `expr` command.
We now have a completion handler in the expression CommandObject that
essentially just attempts to parse the given user expression with Clang with
an attached code completion consumer. We filter and prepare the
code completions provided by Clang and send them back to the completion
API.
The current completion is limited to variables that are in the current scope.
This includes local variables and all types used by local variables. We however
don't do any completion of symbols that are not used in the local scope (or
in some other way already in the ASTContext).
This is partly because there is not yet any code that manually searches for additiona
information in the debug information. Another cause is that for some reason the existing
code for loading these additional symbols when requested by Clang doesn't seem to work.
This will be fixed in a future patch.
Reviewers: jingham, teemperor
Reviewed By: teemperor
Subscribers: labath, aprantl, JDevlieghere, friss, lldb-commits
Differential Revision: https://reviews.llvm.org/D48465
llvm-svn: 341086
This patch extends the SBAPI to allow for setting a breakpoint not
only at a specific line, but also at a specific (minimum) column. When
a column is specified, it will try to find an exact match or the
closest match on the same line that comes after the specified
location.
Differential Revision: https://reviews.llvm.org/D51461
llvm-svn: 341078
On macOS, some of the <optional> APIs used by the test are available only
starting on macOS 10.14 when using exceptions. Build the test with
-fno-exceptions so that the test builds on older systems too.
rdar://problem/43700544
llvm-svn: 340676
- Added LibcxxFunctionSummaryProvider
- Removed LibcxxFunctionFrontEnd
- Modified data formatter tests to test new summary functionality
Patch by Shafik Yaghmour!
Differential Revision: https://reviews.llvm.org/D50864
llvm-svn: 340543
Patch by Shafik Yaghmour!
This reapplies an earlier version after addressing some post-commit feedback.
Differential Revision: https://reviews.llvm.org/D49271
llvm-svn: 339828
clang doesn't use line number 0 (to mean artifically generated code) very often, but swift does it
quite often. We were rejecting all by line breakpoints in functions that started at line 0. But that's
a special marker so we can just not do this test in that case.
llvm-svn: 339182
In this patch I add support for ARM and ARM64 break pad files. There are two flavors of ARM: Apple where FP is R7, and non Apple where FP is R11. Added minimal tests that load up ARM64 and the two flavors or ARM core files with a single thread and known register values in each register. Each register is checked for the exact value.
This is a fixed version of: https://reviews.llvm.org/D49750
The changes from D49750 are:
Don't init the m_arch in the Initialize call as a system info isn't required. This keeps the thread list, module list and other tests from failing
Added -Wextended-offsetof to Xcode project so we catch use extended usages of offsetof before submission
Fixed any extended offset of warnings
Differential Revision: https://reviews.llvm.org/D50336
llvm-svn: 339032
This reverts commit r338734 (and subsequent fixups in r338772 and
r338746), because it breaks some minidump unit tests and introduces a
lot of compiler warnings.
llvm-svn: 338828
Summary:
1) Several tests that are flakey on windows fail the run even if they are marked as expected to be flakey. This is because they fail frequently enough that even a retry won't help
2) Skip several tests on Windows that will occasionally hang rather than failing or exiting. This is causing the entire test suite to hang
Reviewers: asmith, labath, zturner
Reviewed By: zturner
Differential Revision: https://reviews.llvm.org/D50198
llvm-svn: 338769
In this patch I add support for ARM and ARM64 break pad files. There are two flavors of ARM: Apple where FP is R7, and non Apple where FP is R11. Added minimal tests that load up ARM64 and the two flavors or ARM core files with a single thread and known register values in each register. Each register is checked for the exact value.
Differential Revision: https://reviews.llvm.org/D49750
llvm-svn: 338734
As Jim pointed out, we don't need to manually create a target
here because we already create a target implicitly in the very
next line (which means we just created a target and don't use it).
This patch just removes the line that creates the first unused target.
llvm-svn: 338657
Summary: Otherwise this assertion message is not very useful to whoever is reading the log.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D49947
llvm-svn: 338179
Summary: Stopgap patch to at least stop all the crashes I get from this code.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D49949
llvm-svn: 338177
Summary:
The test suite has often unnecessary trailing whitespace, and sometimes
unnecessary trailing lines or a missing final new line. This patch just strips
trailing whitespace/lines and adds missing newlines at the end.
Subscribers: ki.stfu, JDevlieghere, christof, lldb-commits
Differential Revision: https://reviews.llvm.org/D49943
llvm-svn: 338171
This broke a linux bot which doesn't support -std=c++17. The solution
is to add a decorator to skip these tests on machines with older compilers.
llvm-svn: 338162
This should have all the correct files now.
<rdar://problem/41471112>
Patch by Shafik Yaghmour.
Differential Revision: https://reviews.llvm.org/D49271
llvm-svn: 338156
Summary:
So far lldb is printing this when it finds an ambiguous command:
```
(lldb) g
Ambiguous command 'g'. Possible matches:
gdb-remote
gui
gdb-remote
gui
```
The duplicates come from the fact that we call the same query twice with the same parameters
and add it to the same list. This patch just removes the second query call to `GetCommandObject`.
As `GetCommandObject` is const and the name parameter is also not modified, this shouldn't break
anything else. I didn't merge the remaining if statement into the else as I think otherwise the
`if obj==nullptr do X else Y` pattern in there becomes hard to recognize.
Reviewers: davide
Reviewed By: davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D49866
llvm-svn: 338043
Summary:
We always print two error messages when we hit an unknown command. As the function
`CommandInterpreter::HandleCommand` that prints the second error message unconditionally called the `CommandInterpreter::ResolveCommandImpl` before (which prints the first error message), we can just remove
that second error message.
Fixes https://bugs.llvm.org/show_bug.cgi?id=38312
Reviewers: labath
Reviewed By: labath
Subscribers: labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D49831
llvm-svn: 338040
clang recently started diagnosing "exception specification in
declaration does not match previous declaration" errors. Unfortunately
old libc++ versions had a bug, where they violated this rule, which
means that tests using this library version now fail due to build
errors.
Since it was easy to work around the bug by compiling this test with
-fno-exceptions, I do that here. If supporting old libc++ versions
becomes a burden, we'll have to revisit this.
llvm-svn: 337173
The synthetic child providers for these classes had a type expression that matched
pointers & references to the type, but the Front End only worked on the actual object.
I fixed this by adding a way for the Synthetic Child FrontEnd provider to request dereference,
and then had these formatters use that mode.
<rdar://problem/40849836>
Differential Revision: https://reviews.llvm.org/D49279
llvm-svn: 337035
TestAttachDenied tries to attach to a process that is ptracing itself and
verifies that we error out. Starting with macOS Mojave, processes need
an entitlement to be able to ptrace. This commit adds the entitlement for
the test binary when building on Darwin.
llvm-svn: 337029
On systems where it's not supported.
As far as I understand Linux is the only systems which now ships
with libstdcxx (maybe NetBSD?, but I'm not entirely sure of the
state of lldb on the platform).
We could make this more fine grained looking for the header as
we do for libcxx. This is a little tricky as there's no such
thing as /usr/include/c++/v1, but libstdcxx encodes the version
number in the path (i.e. /usr/include/c++/5.4). I guess we might
match a regex, but it seems fragile to me.
Differential Revision: https://reviews.llvm.org/D49110
llvm-svn: 336724
This generalizes a bunch of target-specific tests. MacOS has no
libstdcxx anymore, and neither does FreeBSD (or Windows).
<rdar://problem/41896105>
llvm-svn: 336463
This test was trying to stop at a variety of std::vector calls. It looks like the test
was failing because various inlined std functions left no line table entries for the line that
invoked the inlined function. The author worked around that by undefining _LIBCPP_INLINE_VISIBILITY.
That's an internal libcxx macro, we really shouldn't be playing around with it. Better to just force
ourselves to stop where we want using some other non-inlineable statement. printf seems a good candidate...
<rdar://problem/41867390>
llvm-svn: 336397
Summary:
This change fixes one issue with `lldb.command`, and also reduces the implementation.
The fix: a command function's docstring was not shown when running `help <command_name>`. This is because the docstring attached the source function is not propagated to the decorated function (`f.__call__`). By returning the original function, the docstring will be properly displayed by `help`.
Also with this change, the command name is assumed to be the function's name, but can still be explicitly defined as previously.
Additionally, the implementation was updated to:
* Remove inner class
* Remove use of `inspect` module
* Remove `*args` and `**kwargs`
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: keith, xiaobai, lldb-commits
Differential Revision: https://reviews.llvm.org/D48658
llvm-svn: 336287
Summary:
1) When ReadRegister is called with a null register into on Windows, rather than crashing due to an access violation, simply return false. Not all registers and properties will be read or calculated correctly, but that is consistent with other platforms that also return false in that case
2) Update a couple of tests to reference pr37995 as their reason for failure since it is much more accurate. Support for floating point registers doesn't exist on Windows at all, rather than having issues.
Reviewers: asmith, labath, zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48844
llvm-svn: 336147
This provides an efficient (at least on Posix platforms) way to offload to the
target process the search & loading of a library when all we have are the
library name and a set of potential candidate locations.
<rdar://problem/40905971>
llvm-svn: 335912
Summary: On Windows, the newer DIA SDKs end up producing function names that contain the return type as well. This means that the function name returned in the test will contain the return type (int) in addition to the name of the function and the type of the input (a(int)). To account for the possibility of both, the test should pass if the function name matches either pattern.
Reviewers: zturner, asmith
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48654
llvm-svn: 335906
Summary:
To successfully open a core file, we need to have LLVM built with
support for the relevant target. Right now, if one does not have the
appropriate targets configured, the tests will fail.
This patch uses the GetBuildConfiguration SB API to inform the test (and
anyone else who cares) about the list of supported LLVM targets. The
test then uses this information to approriately skip the tests.
Reviewers: clayborg, jingham
Subscribers: martong, lldb-commits
Differential Revision: https://reviews.llvm.org/D48641
llvm-svn: 335859
pseudo_barrier_wait() begins by decrementing an atomic variable. Since
these are always_inline in libc++, there is no line table anchor to
break on before we decrement it. This meant that on gcc we stopped after
the variable has been decremented, which meant that thread2 could have
exited, violating the test setup. On clang this wasn't a problem
because it generated some line table entries for the do{}while(0) loop
in the macro, so we still ended up stopping, before we touched the
variable.
I fix this by adding a dummy statement before the pseudo_barrier_wait()
command and setting the breakpoint there.
llvm-svn: 335476
Filenames with test results contain only the class name which makes it more
difficult to find it if the same class name is present in multiple *.py files.
packages/Python/lldbsuite/test/functionalities/step-avoids-no-debug/TestStepNoDebug.py
-class ReturnValueTestCase(TestBase):
+class StepAvoidsNoDebugTestCase(TestBase):
as ReturnValueTestCase is already present in:
packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
-class CreateDuringStepTestCase(TestBase):
+class CrashDuringStepTestCase(TestBase):
as CreateDuringStepTestCase is already present in:
packages/Python/lldbsuite/test/functionalities/thread/create_during_step/TestCreateDuringStep.py
packages/Python/lldbsuite/test/functionalities/thread/step_until/TestStepUntil.py
-class TestCStepping(TestBase):
+class StepUntilTestCase(TestBase):
as TestCStepping is already present in:
packages/Python/lldbsuite/test/lang/c/stepping/TestStepAndBreakpoints.py
llvm-svn: 335431
In a modules build, android is very picky about which symbols are
visible after including libc++ headers (e.g. <cstdio> defines only
std::printf and not ::printf).
This consolidates the tests where this was an issue to always include
the <c???> version of the headers and prefixes the symbols with std:: as
necessary.
Apart from that, there is no functional change in the tests.
llvm-svn: 335149
The problem was that with libc++ the std::unique_lock declaration was
completely inlined, so there was no line table entry in the main.cpp
file to set a breakpoint on. Therefore, the breakpoint got moved to the
next line, but that meant the test would deadlock as the thread would
stop with the lock already held.
I fix that issue by adding a dummy statement before the std::unique_lock
line to anchor the breakpoint.
I think this should fix the issue because of which this test was
disabled on darwin, but someone should verify that before enabling it.
llvm-svn: 335132
The second makefile that was added has implicit rules which meant
that secondprog.cpp would be built once into a secondprog binary,
but it would also be compiled as a.out overwriting the main binary.
This lead to spurious failures.
This commit simplifies the Makefile to build only once with the correct
executable name.
llvm-svn: 334861
on darwin systems and re-execing itself, to creating two
separate test programs; lldb runs the first program and it
exec's the second.
Support for compiling for i386 is going away.
llvm-svn: 334783
Summary:
test_set_working_dir was testing two scenario: failure to set the working dir because of a non existent directory and succeeding to set the working directory. Since the negative case fails on both Linux and Windows, the positive case was never tested. I split the test into two which allows us to always run both the negative and positive cases. The positive case now succeeds on Linux and the negative case still fails.
During the investigation, it turned out that lldbtest.py will try to execute a process launch command up to 3 times if the command failed. This means that we could be covering up intermittent failures by running any test that does process launch multiple times without ever realizing it. I've changed the counter to 1 (though it can still be overwritten with the environment variable).
This change also fixes both the positive and negative cases on Windows. There were a few issues:
1) In ProcessLauncherWindows::LaunchProcess, the error was not retrieved until CloseHandle was possibly called. Since CloseHandle is also a system API, its success would overwrite any existing error that could be retrieved using GetLastError. So by the time the error was retrieved, it was now a success.
2) In DebuggerThread::StopDebugging TerminateProcess was called on the process handle regardless of whether it was a valid handle. This was causing the process to crash when the handle was LLDB_INVALID_PROCESS (0xFFFFFFFF).
3) In ProcessWindows::DoLaunch we need to check that the working directory exists before launching the process to have the same behavior as other platforms which first check the directory and then launch process. This way we also control the exact error string.
Reviewers: labath, zturner, asmith, jingham
Reviewed By: labath
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48050
llvm-svn: 334642
This patch adds a data formatter for NSDecimalNumber. The latter is a
Foundation object used for representing and performing arithmetic on
base-10 numbers that bridges to Decimal.
Differential revision: https://reviews.llvm.org/D48114
llvm-svn: 334638
There was no way to find out what's wrong if SBProcess SBTarget::LoadCore(const char *core_file) failed.
Additionally, the implementation was unconditionally setting sb_process, so it wasn't even possible to check if the return SBProcess is valid.
This change adds a new overload which surfaces the errors and also returns a valid SBProcess only if the core load succeeds:
SBProcess SBTarget::LoadCore(const char *core_file, SBError &error);
Differential Revision: https://reviews.llvm.org/D48049
llvm-svn: 334439
Summary: Check case when _M_t child member is not present.
Reviewers: labath, tberghammer
Reviewed By: labath, tberghammer
Differential Revision: https://reviews.llvm.org/D47932
Patch by Aleksandr Urakov <aleksandr.urakov@jetbrains.com>.
llvm-svn: 334411
Summary: They all correspond to bugs that are already logged and I've added the appropriate (or most appropriate) bug numbers. This leaves only a handful of failing tests.
Reviewers: asmith, zturner, labath
Reviewed By: zturner
Subscribers: eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D47892
llvm-svn: 334210
It's been failing since I enabled the test for non-darwin targets. I
made it reference the same bug as the linux core, as it's likely that
the root cause is the same.
llvm-svn: 333401
Summary:
The plugin already builds fine on other platforms (linux, at least). All
that was necessary was to revitalize the hack in PlatformDarwinKernel
(not a very pretty hack, but it gets us going at least).
I haven't done a thorough investigation of the state of the plugin on
other platforms, but at least the two core file tests we have seem to
pass, so I enable them.
Reviewers: JDevlieghere, jasonmolenda
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D47133
llvm-svn: 332997
In r265181 the test for the NSCFBoolean data formatter was removed.
Later, in r279353 and r279446 a new implementation was provided for the
formatter, which I believe never worked (and this wasn't caught because
the test was never re-enabled).
This commit fixes the bug and re-enables the old test case.
Differential revision: https://reviews.llvm.org/D47014
llvm-svn: 332700
Summary: These three tests are failing on Windows and looking into the failures, they could be mapped to pr21765 and pr24489
Reviewers: asmith, labath, zturner
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47018
llvm-svn: 332629
Summary:
1) In logtest.cpp, the name of the file that is reported is not always capitalized, so split the comparison to validate the file (case insensitive) and function (case sensitive) separately
2) Update the gdb remote client tests to work with Python 3. In Python 3, socket sends/receives data as bytes rather than byte strings. This also updates the usage of .hex() - this is no longer available in Python 3, so use hexlify instead
Reviewers: asmith, labath, zturner
Reviewed By: labath
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46773
llvm-svn: 332293
Summary:
1) In TestLinuxCore rather than skipping the tests on Windows, mark them as expected failures and add a bug reference
2) In dotest.py replace the undefined property in the exceptions with the actual property causing the exception
Reviewers: asmith, labath, zturner
Reviewed By: labath, zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46590
llvm-svn: 331886
Summary:
In decorators.py, when opening streams, open them in text mode. In Py3, if they are not opened in text mode, the data is also expected to be binary, but we always use text data.
In TestLinuxCore, skip the tests that are not applicable on Windows
In the python api main.c, update the code to be compilable on Windows
Reviewers: asmith, zturner
Reviewed By: zturner
Subscribers: zturner
Differential Revision: https://reviews.llvm.org/D46440
llvm-svn: 331686
Aleksandr Urakov