These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall code layering (although it still does not break any particular
dependency completely).
The XCode project will need to be updated after this change.
Differential Revision: https://reviews.llvm.org/D49740
llvm-svn: 339127
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
Most non-local includes of header files living under lldb/sources/
were specified with the full path starting after sources/. However, in
a few instances, other sub-directories were added to include paths, or
Normalize those few instances to follow the style used by the rest of
the codebase, to make it easier to understand.
llvm-svn: 333035
Summary: LLDB reads wrong registers on 64bit Windows because RegisterContextWindows_x64::GetRegisterInfoAtIndex returns wrong reference.
I encountered broken backtrace when the program stopped at function which does not have prologue code, such as compiled with '-fomit-frame-pointer'.
In this situation, CFA is equal to rsp but LLDB reads r9.
RegisterContextWindows_x64::GetRegisterInfoAtIndex depends the order of lldb_XXX_x86_64 values, but RegisterIndex/g_register_infos/g_gpr_reg_indices does not follow order.
In source/Plugins/Process/Utility/lldb-x86-register-enums.h
The order of GPRs is rax, rbx, rcx, rdx, rdi, rsi, rbp, rsp, r8, ...
In source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp
The order of GPRs is rax, rbx, rcx, rdx, rdi, rsi, r8, r9, r10, ...
Patch by Kenji Koyanagi
llvm-svn: 332671
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.
llvm-svn: 302872
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
*** 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
return NULL for an invalid register.
The unwind logic asks for the "return address register" which doesn't exist
on x86/x86_64, returns -1 and calls this with -1 as a parameter, ends up
out of scope of the array bounds for g_register_infos and later SIGSEGVs
on accessing. This now matches the other GetRegisterInfoAtIndex for
other platforms.
llvm-svn: 271876
Pavel Labath