Checks that at at least qRegisterInfo0 responds with a valid
register info reply packet. The packet is parsed and validates
that all keys come from the documented set of valid keys. It
then validates that a minimum set of expected keys
are present in the returned packet.
This test is set to pass on debugserver and fail on llgs TOT.
llvm-svn: 209109
debugserver now returns $X09 as the immediate response to
a $k kill process request rather than $W09.
ProcessGDBRemote now properly handles X as indication of
a process exit state.
The @debugserver_test and @lldb_test for $k now properly expects
an X notification (signal-caused exit) after killing a just-attached
inferior that was still in the stopped state.
llvm-svn: 209108
SVN r209103 removed the OwningPtr variant of the MemoryBuffer APIs. Switch to
the equivalent std::unique_ptr versions. This should clear up the build bots.
llvm-svn: 209104
r179585 introduced different MSPropertyRefExpr visitation for RAV and DRAV that
appears to have been unintentional. Let's use the more complete one.
llvm-svn: 209101
The instrprofile-write-file-only test was failing on the builtbots. The runtime
library initialization is explicitly being discarded to avoid the atexit hook.
However, this would also prevent the filename from being initialized. Thus,
when the write file was invoked, the filename would not be setup, and the test
would fail as the profiling data would never be written out. Explicitly
initialize the filename to ensure that the data is written out when requested.
This should hopefully finally get the build bots all green again.
llvm-svn: 209099
dlopen expects that the flags contains RTLD_LAZY or RTLD_NOW. RTLD_LAZY will
resolve the symbol on first use, and is generally preferred due to efficiency.
Add this to fix the test failure on the build bots.
llvm-svn: 209098
Add logging to report any failures that may occur on calls to libdl. Without
this, it is difficult to identify the actual problem if the test fails.
llvm-svn: 209097
Add an explicit link against libdl. libdl may not be indirectly pulled on some
Linux hosts. Explicitly link against it. This should hopefully improve the
state of the build bots.
llvm-svn: 209096
Extend the function definition macros further to support COFF object emission.
The function definition in COFF includes the type and storage class in the
symbol definition context. This is needed to make the assembly routines
possible to be built for COFF environments (i.e. Windows).
llvm-svn: 209095
Rename the HIDDEN_DIRECTIVE macro to HIDDEN and give it a parameter providing
the name of the symbol to be given hidden visibility. This makes the macros
more amenable to COFF.
llvm-svn: 209094
* Shuffle around code to reduce delta between the two RAVs.
* Merge r189185 that was applied only to one of the RAVs and became apparent during the unification work.
* Fix Enqueue data recursion typo.
Our delta is down to +-579!
llvm-svn: 209093
Apply current ToT clang-format on the two RAVs to reduce delta and help
identify differences between the two.
We lose a little pretty formatting in the headers but that's the price to pay
so we can diff these two files effectively and look to a future where we don't
have to maintain two copies of this code.
Formatting and whitespace only.
llvm-svn: 209092
Define a macro to reduce the delta between RecursiveASTVisitor and
DataRecursiveASTVisitor.
Some years ago, someone thought it was a good idea to copy the entire RAV to
support cursor visitation in libclang.
Since then the two have diverged needlessly and the rest is history.
This series of commits aims to reduce delta between the two so that we can
reason about their differences, apply bugfixes that were only made to one but
not the other, and ultimately find a way to unify two two chunks of code.
llvm-svn: 209091
Rather than create a series of function calls to setup the library calls, create
a table with the information and just use the table to drive the configuration
of the library calls. This makes it easier to both inspect the list as well as
to modify it. NFC.
llvm-svn: 209089
While there make getOption return a const reference so we don't have to put it
on the stack when calling methods on it. No functionality change.
llvm-svn: 209088
Windows on ARM expects ARMv8 (restricted IT) conditional instructions only.
Force enable the restricted IT mode via the backend option when targeting WoA.
llvm-svn: 209086
Windows on ARM uses R11 for the frame pointer even though the environment is a
pure Thumb-2, thumb-only environment. Replicate this behaviour to improve
Windows ABI compatibility. This register is used for fast stack walking, and
thus is part of the Windows ABI.
llvm-svn: 209085
Use the ARMBaseRegisterInfo to query the frame register. The base register info
is aware of the frame register that is used for the frame pointer. Use that to
determine the frame register rather than duplicating the knowledge. Although,
the code path is slightly different in that it may return SP, that can only
occur if the frame pointer has been omitted in the machine function, which is
supposed to contain the desired value in that case.
llvm-svn: 209084
This is mostly a mechanical change changing all the call sites to the newer
chained-function construction pattern. This removes the horrible 15-parameter
constructor for the CallLoweringInfo in favour of setting properties of the call
via chained functions. No functional change beyond the removal of the old
constructors are intended.
llvm-svn: 209082
Rather than introducing an auxiliary CallLoweringInfoBuilder, add the methods to
do chained function construction directly to CallLoweringInfo. This reduces the
monstrous 15-parameter constructor into a series of simpler (for some definition
of simpler) functions that control particular aspects of the call. The old
interfaces can be completely removed once callers are moved to the new chained
constructor pattern.
llvm-svn: 209081
This is a preliminary step to help ease the construction of CallLoweringInfo.
Changing the construction to a chained function pattern requires that the
parameter be nullable. However, rather than copying the vector, save a pointer
rather than the reference to permit a late binding of the arguments.
llvm-svn: 209080
Rationale:
Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as
std::__1::vector<int, std::__1::allocator<....
rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code
Proposed solution:
Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name
Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point
LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem
Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice
The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one
It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type
Caveats:
- for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet.
- while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters
llvm-svn: 209072
These are now treated as environments. Remove references to these enumeration
values in order to clean up the unused enumeration entries in LLVM. The target
normalisation prior to tool invocation should ensure that the old values
continue to function properly.
llvm-svn: 209068
When pruning superfluous MachO structure definitions, I chose to keep
the most generically useful which is why Support's definitions won over
the ones in MC.
However, the MC copy had some useful comments describing some of the
field values.
Bring these back to the copy in Support. While doing this, fill in some
of the underdocumented definitions as well.
llvm-svn: 209066
This patch fixes 3 issues introduced by r209049 that only showed up in on
the sanitizer buildbots. One was a typo in a compare. The other is a check to
confirm that the single differing value in the two incoming GEPs is the same
type. The final issue was the the IRBuilder under some circumstances would
build PHIs in the middle of the block.
llvm-svn: 209065
Dinesh Dwivedi