maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/Utility/Scalar.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

2900 lines
72 KiB
C++
Raw Normal View History

[lldb][NFC] Fix all formatting errors in .cpp file headers Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 15:23:27 +08:00
//===-- Scalar.cpp --------------------------------------------------------===//
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//
//===----------------------------------------------------------------------===//
Move RegisterValue,Scalar,State from Core to Utility 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
2018-08-07 19:07:21 +08:00
#include "lldb/Utility/Scalar.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Move DataBuffer / DataExtractor and friends from Core -> Utility. llvm-svn: 296943
2017-03-04 09:30:05 +08:00
#include "lldb/Utility/DataExtractor.h"
Remove dependencies from Utility to Core and Target. With this patch, the only dependency left is from Utility to Host. After this is broken, Utility will finally be standalone. Differential Revision: https://reviews.llvm.org/D29909 llvm-svn: 295088
2017-02-15 03:06:07 +08:00
#include "lldb/Utility/Endian.h"
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
#include "lldb/Utility/Status.h"
Move classes from Core -> Utility. 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
2017-02-03 05:39:50 +08:00
#include "lldb/Utility/Stream.h"
DWARFExpression: Fix implementation of DW_OP_pick Summary: The DWARF spec states that the DWARF stack arguments are numbered from the top. Our implementation of DW_OP_pick was counting them from the bottom. This bug probably wasn't noticed because nobody (except my upcoming postfix-to-DWARF converter) uses DW_OP_pick, but I've cross-checked with gdb to confirm that counting from the top is the expected behavior. This patch fixes the implementation to match the spec and gdb behavior and adds a test. Reviewers: jasonmolenda, clayborg Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D61182 llvm-svn: 359436
2019-04-29 18:55:22 +08:00
#include "lldb/Utility/StreamString.h"
Remove comments after header includes. This patch removes the comments following the header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. Differential revision: https://reviews.llvm.org/D54385 llvm-svn: 346625
2018-11-12 07:16:43 +08:00
#include "lldb/lldb-types.h"
iwyu fixes for lldbCore. This adjusts header file includes for headers and source files in Core. In doing so, one dependency cycle is eliminated because all the includes from Core to that project were dead includes anyway. In places where some files in other projects were only compiling due to a transitive include from another header, fixups have been made so that those files also include the header they need. Tested on Windows and Linux, and plan to address failures on OSX and FreeBSD after watching the bots. llvm-svn: 299714
2017-04-07 05:28:29 +08:00
#include "llvm/ADT/SmallString.h"
#include <cinttypes>
#include <cstdio>
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
using namespace lldb;
using namespace lldb_private;
Reflow paragraphs in comments. 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
2018-05-01 00:49:04 +08:00
// Promote to max type currently follows the ANSI C rule for type promotion in
// expressions.
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
static Scalar::Type PromoteToMaxType(
const Scalar &lhs, // The const left hand side object
const Scalar &rhs, // The const right hand side object
Scalar &temp_value, // A modifiable temp value than can be used to hold
// either the promoted lhs or rhs object
const Scalar *&promoted_lhs_ptr, // Pointer to the resulting possibly
// promoted value of lhs (at most one of
// lhs/rhs will get promoted)
const Scalar *&promoted_rhs_ptr // Pointer to the resulting possibly
// promoted value of rhs (at most one of
// lhs/rhs will get promoted)
Move RegisterValue,Scalar,State from Core to Utility 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
2018-08-07 19:07:21 +08:00
) {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar result;
Reflow paragraphs in comments. 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
2018-05-01 00:49:04 +08:00
// Initialize the promoted values for both the right and left hand side
// values to be the objects themselves. If no promotion is needed (both right
// and left have the same type), then the temp_value will not get used.
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
promoted_lhs_ptr = &lhs;
promoted_rhs_ptr = &rhs;
// Extract the types of both the right and left hand side values
Scalar::Type lhs_type = lhs.GetType();
Scalar::Type rhs_type = rhs.GetType();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (lhs_type > rhs_type) {
// Right hand side need to be promoted
temp_value = rhs; // Copy right hand side into the temp value
if (temp_value.Promote(lhs_type)) // Promote it
promoted_rhs_ptr =
&temp_value; // Update the pointer for the promoted right hand side
} else if (lhs_type < rhs_type) {
// Left hand side need to be promoted
temp_value = lhs; // Copy left hand side value into the temp value
if (temp_value.Promote(rhs_type)) // Promote it
promoted_lhs_ptr =
&temp_value; // Update the pointer for the promoted left hand side
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Fix typos. llvm-svn: 212132
2014-07-02 05:22:11 +08:00
// Make sure our type promotion worked as expected
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (promoted_lhs_ptr->GetType() == promoted_rhs_ptr->GetType())
return promoted_lhs_ptr->GetType(); // Return the resulting max type
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// Return the void type (zero) if we fail to promote either of the values.
return Scalar::e_void;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
Scalar::Scalar() : m_type(e_void), m_float(static_cast<float>(0)) {}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool Scalar::GetData(DataExtractor &data, size_t limit_byte_size) const {
size_t byte_size = GetByteSize();
if (byte_size > 0) {
[lldb][NFC] Use static_cast instead of reinterpret_cast where possible Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`. Reviewers: shafik, JDevlieghere, labath Reviewed By: labath Subscribers: arphaman, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72161
2020-01-07 19:13:03 +08:00
const uint8_t *bytes = static_cast<const uint8_t *>(GetBytes());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (limit_byte_size < byte_size) {
Make lldb::endian::InlHostByteOrder() private. Summary: Since this is within the lldb namespace, the compiler tries to export a symbol for it. Unfortunately, since it is inlined, the symbol is hidden and this results in a mess of warnings when building on OS X with cmake. Moving it to the lldb_private namespace eliminates that problem. Reviewers: clayborg Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D14417 llvm-svn: 252396
2015-11-07 12:40:13 +08:00
if (endian::InlHostByteOrder() == eByteOrderLittle) {
Reflow paragraphs in comments. 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
2018-05-01 00:49:04 +08:00
// On little endian systems if we want fewer bytes from the current
// type we just specify fewer bytes since the LSByte is first...
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
byte_size = limit_byte_size;
Make lldb::endian::InlHostByteOrder() private. Summary: Since this is within the lldb namespace, the compiler tries to export a symbol for it. Unfortunately, since it is inlined, the symbol is hidden and this results in a mess of warnings when building on OS X with cmake. Moving it to the lldb_private namespace eliminates that problem. Reviewers: clayborg Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D14417 llvm-svn: 252396
2015-11-07 12:40:13 +08:00
} else if (endian::InlHostByteOrder() == eByteOrderBig) {
Reflow paragraphs in comments. 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
2018-05-01 00:49:04 +08:00
// On big endian systems if we want fewer bytes from the current type
// have to advance our initial byte pointer and trim down the number of
// bytes since the MSByte is first
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
bytes += byte_size - limit_byte_size;
byte_size = limit_byte_size;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
data.SetData(bytes, byte_size, endian::InlHostByteOrder());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
data.Clear();
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
const void *Scalar::GetBytes() const {
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
const uint64_t *apint_words;
const uint8_t *bytes;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
static float_t flt_val;
static double_t dbl_val;
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
static uint64_t swapped_words[8];
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
switch (m_type) {
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
bytes = reinterpret_cast<const uint8_t *>(m_integer.getRawData());
Reflow paragraphs in comments. 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
2018-05-01 00:49:04 +08:00
// getRawData always returns a pointer to an uint64_t. If we have a
// smaller type, we need to update the pointer on big-endian systems.
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
if (endian::InlHostByteOrder() == eByteOrderBig) {
size_t byte_size = m_integer.getBitWidth() / 8;
if (byte_size < 8)
bytes += 8 - byte_size;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
return bytes;
[Scalar] Hoist a duplicated (and sometimes wrong) comment. Pointed out by Zachary and Adrian. llvm-svn: 352641
2019-01-31 02:24:16 +08:00
// getRawData always returns a pointer to an array of uint64_t values,
// where the least-significant word always comes first. On big-endian
// systems we need to swap the words.
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
case e_uint128:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
apint_words = m_integer.getRawData();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (endian::InlHostByteOrder() == eByteOrderBig) {
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
swapped_words[0] = apint_words[1];
swapped_words[1] = apint_words[0];
apint_words = swapped_words;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[lldb][NFC] Use static_cast instead of reinterpret_cast where possible Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`. Reviewers: shafik, JDevlieghere, labath Reviewed By: labath Subscribers: arphaman, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72161
2020-01-07 19:13:03 +08:00
return static_cast<const void *>(apint_words);
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
apint_words = m_integer.getRawData();
if (endian::InlHostByteOrder() == eByteOrderBig) {
swapped_words[0] = apint_words[3];
swapped_words[1] = apint_words[2];
swapped_words[2] = apint_words[1];
swapped_words[3] = apint_words[0];
apint_words = swapped_words;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[lldb][NFC] Use static_cast instead of reinterpret_cast where possible Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`. Reviewers: shafik, JDevlieghere, labath Reviewed By: labath Subscribers: arphaman, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72161
2020-01-07 19:13:03 +08:00
return static_cast<const void *>(apint_words);
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
apint_words = m_integer.getRawData();
if (endian::InlHostByteOrder() == eByteOrderBig) {
swapped_words[0] = apint_words[7];
swapped_words[1] = apint_words[6];
swapped_words[2] = apint_words[5];
swapped_words[3] = apint_words[4];
swapped_words[4] = apint_words[3];
swapped_words[5] = apint_words[2];
swapped_words[6] = apint_words[1];
swapped_words[7] = apint_words[0];
apint_words = swapped_words;
}
[lldb][NFC] Use static_cast instead of reinterpret_cast where possible Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`. Reviewers: shafik, JDevlieghere, labath Reviewed By: labath Subscribers: arphaman, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72161
2020-01-07 19:13:03 +08:00
return static_cast<const void *>(apint_words);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
flt_val = m_float.convertToFloat();
[lldb][NFC] Use static_cast instead of reinterpret_cast where possible Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`. Reviewers: shafik, JDevlieghere, labath Reviewed By: labath Subscribers: arphaman, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72161
2020-01-07 19:13:03 +08:00
return static_cast<const void *>(&flt_val);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
dbl_val = m_float.convertToDouble();
[lldb][NFC] Use static_cast instead of reinterpret_cast where possible Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`. Reviewers: shafik, JDevlieghere, labath Reviewed By: labath Subscribers: arphaman, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72161
2020-01-07 19:13:03 +08:00
return static_cast<const void *>(&dbl_val);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
llvm::APInt ldbl_val = m_float.bitcastToAPInt();
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
apint_words = ldbl_val.getRawData();
// getRawData always returns a pointer to an array of two uint64_t values,
// where the least-significant word always comes first. On big-endian
// systems we need to swap the two words.
if (endian::InlHostByteOrder() == eByteOrderBig) {
swapped_words[0] = apint_words[1];
swapped_words[1] = apint_words[0];
apint_words = swapped_words;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[lldb][NFC] Use static_cast instead of reinterpret_cast where possible Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`. Reviewers: shafik, JDevlieghere, labath Reviewed By: labath Subscribers: arphaman, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72161
2020-01-07 19:13:03 +08:00
return static_cast<const void *>(apint_words);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 263312
2016-03-12 08:31:13 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
size_t Scalar::GetByteSize() const {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (m_type) {
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_uint128:
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
return (m_integer.getBitWidth() / 8);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
return sizeof(float_t);
case e_double:
return sizeof(double_t);
case e_long_double:
return sizeof(long_double_t);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return 0;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool Scalar::IsZero() const {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
llvm::APInt zero_int = llvm::APInt::getNullValue(m_integer.getBitWidth() / 8);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (m_type) {
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_uint128:
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_uint512:
case e_sint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
return llvm::APInt::isSameValue(zero_int, m_integer);
case e_float:
case e_double:
case e_long_double:
return m_float.isZero();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void Scalar::GetValue(Stream *s, bool show_type) const {
if (show_type)
s->Printf("(%s) ", GetTypeAsCString());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (m_type) {
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_slong:
case e_slonglong:
case e_sint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
Fix Clang-tidy readability-redundant-string-cstr warnings Reviewers: zturner, labath Subscribers: tberghammer, danalbert, lldb-commits Differential Revision: https://reviews.llvm.org/D26233 llvm-svn: 285855
2016-11-03 04:34:10 +08:00
s->PutCString(m_integer.toString(10, true));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_uint:
case e_ulong:
case e_ulonglong:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_uint512:
Fix Clang-tidy readability-redundant-string-cstr warnings Reviewers: zturner, labath Subscribers: tberghammer, danalbert, lldb-commits Differential Revision: https://reviews.llvm.org/D26233 llvm-svn: 285855
2016-11-03 04:34:10 +08:00
s->PutCString(m_integer.toString(10, false));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
case e_double:
case e_long_double:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
llvm::SmallString<24> string;
m_float.toString(string);
s->Printf("%s", string.c_str());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
const char *Scalar::GetTypeAsCString() const {
switch (m_type) {
case e_void:
return "void";
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
case e_sint:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return "int";
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
case e_uint:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return "unsigned int";
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
case e_slong:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return "long";
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
case e_ulong:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return "unsigned long";
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
case e_slonglong:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return "long long";
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
case e_ulonglong:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return "unsigned long long";
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
return "int128_t";
case e_uint128:
return "unsigned int128_t";
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
return "int256_t";
case e_uint256:
return "unsigned int256_t";
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
return "int512_t";
case e_uint512:
return "unsigned int512_t";
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
case e_float:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return "float";
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return "double";
case e_long_double:
return "long double";
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return "<invalid Scalar type>";
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar &Scalar::operator=(const int v) {
m_type = e_sint;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer = llvm::APInt(sizeof(int) * 8, v, true);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return *this;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar &Scalar::operator=(unsigned int v) {
m_type = e_uint;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer = llvm::APInt(sizeof(int) * 8, v);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return *this;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar &Scalar::operator=(long v) {
m_type = e_slong;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer = llvm::APInt(sizeof(long) * 8, v, true);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return *this;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar &Scalar::operator=(unsigned long v) {
m_type = e_ulong;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer = llvm::APInt(sizeof(long) * 8, v);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return *this;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar &Scalar::operator=(long long v) {
m_type = e_slonglong;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer = llvm::APInt(sizeof(long) * 8, v, true);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return *this;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar &Scalar::operator=(unsigned long long v) {
m_type = e_ulonglong;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer = llvm::APInt(sizeof(long long) * 8, v);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return *this;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar &Scalar::operator=(float v) {
m_type = e_float;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_float = llvm::APFloat(v);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return *this;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar &Scalar::operator=(double v) {
m_type = e_double;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_float = llvm::APFloat(v);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return *this;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar &Scalar::operator=(long double v) {
m_type = e_long_double;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
if (m_ieee_quad)
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEquad(),
llvm::APInt(BITWIDTH_INT128, NUM_OF_WORDS_INT128,
(reinterpret_cast<type128 *>(&v))->x));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
else
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
m_float = llvm::APFloat(llvm::APFloat::x87DoubleExtended(),
llvm::APInt(BITWIDTH_INT128, NUM_OF_WORDS_INT128,
(reinterpret_cast<type128 *>(&v))->x));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return *this;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
Scalar &Scalar::operator=(llvm::APInt rhs) {
m_integer = llvm::APInt(rhs);
switch (m_integer.getBitWidth()) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
case 8:
case 16:
case 32:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
if (m_integer.isSignedIntN(sizeof(sint_t) * 8))
m_type = e_sint;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
else
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_type = e_uint;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case 64:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
if (m_integer.isSignedIntN(sizeof(slonglong_t) * 8))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_type = e_slonglong;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
else
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_type = e_ulonglong;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case 128:
if (m_integer.isSignedIntN(BITWIDTH_INT128))
m_type = e_sint128;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
else
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_type = e_uint128;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case 256:
if (m_integer.isSignedIntN(BITWIDTH_INT256))
m_type = e_sint256;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
else
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
m_type = e_uint256;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case 512:
if (m_integer.isSignedIntN(BITWIDTH_INT512))
m_type = e_sint512;
else
m_type = e_uint512;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
return *this;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
Scalar::~Scalar() = default;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Implement DW_OP_convert This patch adds basic support for DW_OP_convert[1] for integer types. Recent versions of LLVM's optimizer may insert this opcode into DWARF expressions. DW_OP_convert is effectively a type cast operation that takes a reference to a base type DIE (or zero) and then casts the value at the top of the DWARF stack to that type. Internally this works by changing the bit size of the APInt that is used as backing storage for LLDB's DWARF stack. I managed to write a unit test for this by implementing a mock YAML object file / module that takes debug info sections in yaml2obj format. [1] Typed DWARF stack. http://www.dwarfstd.org/ShowIssue.php?issue=140425.1 <rdar://problem/48167864> Differential Revision: https://reviews.llvm.org/D67369 llvm-svn: 371532
2019-09-11 00:17:38 +08:00
Scalar::Type Scalar::GetBestTypeForBitSize(size_t bit_size, bool sign) {
// Scalar types are always host types, hence the sizeof().
if (sign) {
if (bit_size <= sizeof(int)*8) return Scalar::e_sint;
if (bit_size <= sizeof(long)*8) return Scalar::e_slong;
if (bit_size <= sizeof(long long)*8) return Scalar::e_slonglong;
if (bit_size <= 128) return Scalar::e_sint128;
if (bit_size <= 256) return Scalar::e_sint256;
if (bit_size <= 512) return Scalar::e_sint512;
} else {
if (bit_size <= sizeof(unsigned int)*8) return Scalar::e_uint;
if (bit_size <= sizeof(unsigned long)*8) return Scalar::e_ulong;
if (bit_size <= sizeof(unsigned long long)*8) return Scalar::e_ulonglong;
if (bit_size <= 128) return Scalar::e_uint128;
if (bit_size <= 256) return Scalar::e_uint256;
if (bit_size <= 512) return Scalar::e_uint512;
}
return Scalar::e_void;
[LLDB] Remove a stray semicolon. NFC. This fixes build warnings with at least GCC. llvm-svn: 372588
2019-09-23 20:03:14 +08:00
}
Implement DW_OP_convert This patch adds basic support for DW_OP_convert[1] for integer types. Recent versions of LLVM's optimizer may insert this opcode into DWARF expressions. DW_OP_convert is effectively a type cast operation that takes a reference to a base type DIE (or zero) and then casts the value at the top of the DWARF stack to that type. Internally this works by changing the bit size of the APInt that is used as backing storage for LLDB's DWARF stack. I managed to write a unit test for this by implementing a mock YAML object file / module that takes debug info sections in yaml2obj format. [1] Typed DWARF stack. http://www.dwarfstd.org/ShowIssue.php?issue=140425.1 <rdar://problem/48167864> Differential Revision: https://reviews.llvm.org/D67369 llvm-svn: 371532
2019-09-11 00:17:38 +08:00
void Scalar::TruncOrExtendTo(Scalar::Type type, uint16_t bits) {
switch (type) {
case e_sint:
case e_slong:
case e_slonglong:
case e_sint128:
case e_sint256:
case e_sint512:
m_integer = m_integer.sextOrTrunc(bits);
break;
case e_uint:
case e_ulong:
case e_ulonglong:
case e_uint128:
case e_uint256:
case e_uint512:
m_integer = m_integer.zextOrTrunc(bits);
break;
default:
llvm_unreachable("Promoting a Scalar to a specific number of bits is only "
"supported for integer types.");
}
m_type = type;
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
bool Scalar::Promote(Scalar::Type type) {
bool success = false;
switch (m_type) {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Revert r244308 since it's introducing test regressions on Linux: - TestLldbGdbServer.py both clang & gcc, i386 and x86_64 - TestConstVariables.py gcc, i386 and x86_64 - 112 failures clang, i386 llvm-svn: 244514
2015-08-11 05:49:50 +08:00
case e_sint:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
switch (type) {
case e_void:
break;
case e_sint:
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_uint:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.sextOrTrunc(sizeof(uint_t) * 8);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_slong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.sextOrTrunc(sizeof(slong_t) * 8);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_ulong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.sextOrTrunc(sizeof(ulong_t) * 8);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_slonglong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.sextOrTrunc(sizeof(slonglong_t) * 8);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_ulonglong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.sextOrTrunc(sizeof(ulonglong_t) * 8);
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
case e_uint128:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.sextOrTrunc(BITWIDTH_INT128);
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.sextOrTrunc(BITWIDTH_INT256);
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
m_integer = m_integer.sextOrTrunc(BITWIDTH_INT512);
success = true;
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEsingle());
m_float.convertFromAPInt(m_integer, true,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
Make Scalar::GetBytes and RegisterValue::GetBytes const 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
2016-04-14 22:31:08 +08:00
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEdouble());
m_float.convertFromAPInt(m_integer, true,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
Make Scalar::GetBytes and RegisterValue::GetBytes const 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
2016-04-14 22:31:08 +08:00
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(m_ieee_quad ? llvm::APFloat::IEEEquad()
: llvm::APFloat::x87DoubleExtended());
m_float.convertFromAPInt(m_integer, true,
llvm::APFloat::rmNearestTiesToEven);
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
}
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 263312
2016-03-12 08:31:13 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_uint:
switch (type) {
case e_void:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_uint:
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_slong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.zextOrTrunc(sizeof(slong_t) * 8);
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_ulong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.zextOrTrunc(sizeof(ulong_t) * 8);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_slonglong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.zextOrTrunc(sizeof(slonglong_t) * 8);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_ulonglong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.zextOrTrunc(sizeof(ulonglong_t) * 8);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_uint128:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.zextOrTrunc(BITWIDTH_INT128);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
m_integer = m_integer.zextOrTrunc(BITWIDTH_INT256);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
m_integer = m_integer.zextOrTrunc(BITWIDTH_INT512);
success = true;
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEsingle());
m_float.convertFromAPInt(m_integer, false,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEdouble());
m_float.convertFromAPInt(m_integer, false,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(m_ieee_quad ? llvm::APFloat::IEEEquad()
: llvm::APFloat::x87DoubleExtended());
m_float.convertFromAPInt(m_integer, false,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
break;
case e_slong:
switch (type) {
case e_void:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_slong:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_ulong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.sextOrTrunc(sizeof(ulong_t) * 8);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_slonglong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.sextOrTrunc(sizeof(slonglong_t) * 8);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_ulonglong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.sextOrTrunc(sizeof(ulonglong_t) * 8);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
case e_uint128:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.sextOrTrunc(BITWIDTH_INT128);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer = m_integer.sextOrTrunc(BITWIDTH_INT256);
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
m_integer = m_integer.sextOrTrunc(BITWIDTH_INT512);
success = true;
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEsingle());
m_float.convertFromAPInt(m_integer, true,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEdouble());
m_float.convertFromAPInt(m_integer, true,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(m_ieee_quad ? llvm::APFloat::IEEEquad()
: llvm::APFloat::x87DoubleExtended());
m_float.convertFromAPInt(m_integer, true,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_ulong:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (type) {
case e_void:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
case e_sint:
case e_uint:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_slong:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Reapply "Make Scalar::GetValue more consistent" this is a resubmission of r280476. The problem with the original commit was that it was printing out all numbers as signed, which was wrong for unsigned numbers with the MSB set. Fix that and add a unit test covering that case. llvm-svn: 280480
2016-09-02 18:58:52 +08:00
case e_ulong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_slonglong:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer = m_integer.zextOrTrunc(sizeof(slonglong_t) * 8);
success = true;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
case e_ulonglong:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer = m_integer.zextOrTrunc(sizeof(ulonglong_t) * 8);
success = true;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
case e_sint128:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_uint128:
m_integer = m_integer.zextOrTrunc(BITWIDTH_INT128);
success = true;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
case e_sint256:
case e_uint256:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer = m_integer.zextOrTrunc(BITWIDTH_INT256);
success = true;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
m_integer = m_integer.zextOrTrunc(BITWIDTH_INT512);
success = true;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_float:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEsingle());
m_float.convertFromAPInt(m_integer, false,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
case e_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEdouble());
m_float.convertFromAPInt(m_integer, false,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
case e_long_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(m_ieee_quad ? llvm::APFloat::IEEEquad()
: llvm::APFloat::x87DoubleExtended());
m_float.convertFromAPInt(m_integer, false,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
case e_slonglong:
switch (type) {
case e_void:
Revert r244308 since it's introducing test regressions on Linux: - TestLldbGdbServer.py both clang & gcc, i386 and x86_64 - TestConstVariables.py gcc, i386 and x86_64 - 112 failures clang, i386 llvm-svn: 244514
2015-08-11 05:49:50 +08:00
case e_sint:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_uint:
case e_slong:
case e_ulong:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_slonglong:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_ulonglong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.sextOrTrunc(sizeof(ulonglong_t) * 8);
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
success = true;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
break;
case e_sint128:
case e_uint128:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.sextOrTrunc(BITWIDTH_INT128);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
m_integer = m_integer.sextOrTrunc(BITWIDTH_INT256);
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
m_integer = m_integer.sextOrTrunc(BITWIDTH_INT512);
success = true;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_float:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEsingle());
m_float.convertFromAPInt(m_integer, true,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEdouble());
m_float.convertFromAPInt(m_integer, true,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_long_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(m_ieee_quad ? llvm::APFloat::IEEEquad()
: llvm::APFloat::x87DoubleExtended());
m_float.convertFromAPInt(m_integer, true,
llvm::APFloat::rmNearestTiesToEven);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
success = true;
break;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_ulonglong:
switch (type) {
case e_void:
case e_sint:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_ulonglong:
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
case e_uint128:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.zextOrTrunc(BITWIDTH_INT128);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer = m_integer.zextOrTrunc(BITWIDTH_INT256);
success = true;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
m_integer = m_integer.zextOrTrunc(BITWIDTH_INT512);
success = true;
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEsingle());
m_float.convertFromAPInt(m_integer, false,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEdouble());
m_float.convertFromAPInt(m_integer, false,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(m_ieee_quad ? llvm::APFloat::IEEEquad()
: llvm::APFloat::x87DoubleExtended());
m_float.convertFromAPInt(m_integer, false,
llvm::APFloat::rmNearestTiesToEven);
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
success = true;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
break;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
Make Scalar::SChar return an explicit signed type This is needed for platforms where the default "char" type is unsigned. Originally committed as part of (now reverted) r266311. llvm-svn: 266420
2016-04-15 17:15:47 +08:00
case e_sint128:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (type) {
case e_void:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_uint128:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.sextOrTrunc(BITWIDTH_INT128);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.sextOrTrunc(BITWIDTH_INT256);
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
m_integer = m_integer.sextOrTrunc(BITWIDTH_INT512);
success = true;
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEsingle());
m_float.convertFromAPInt(m_integer, true,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEdouble());
m_float.convertFromAPInt(m_integer, true,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(m_ieee_quad ? llvm::APFloat::IEEEquad()
: llvm::APFloat::x87DoubleExtended());
m_float.convertFromAPInt(m_integer, true,
llvm::APFloat::rmNearestTiesToEven);
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_uint128:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (type) {
case e_void:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_uint128:
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.zextOrTrunc(BITWIDTH_INT256);
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
m_integer = m_integer.zextOrTrunc(BITWIDTH_INT512);
success = true;
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEsingle());
m_float.convertFromAPInt(m_integer, false,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEdouble());
m_float.convertFromAPInt(m_integer, false,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(m_ieee_quad ? llvm::APFloat::IEEEquad()
: llvm::APFloat::x87DoubleExtended());
m_float.convertFromAPInt(m_integer, false,
llvm::APFloat::rmNearestTiesToEven);
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint256:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (type) {
case e_void:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_uint256:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.sextOrTrunc(BITWIDTH_INT256);
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
m_integer = m_integer.zextOrTrunc(BITWIDTH_INT512);
success = true;
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEsingle());
m_float.convertFromAPInt(m_integer, true,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEdouble());
m_float.convertFromAPInt(m_integer, true,
llvm::APFloat::rmNearestTiesToEven);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
success = true;
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(m_ieee_quad ? llvm::APFloat::IEEEquad()
: llvm::APFloat::x87DoubleExtended());
m_float.convertFromAPInt(m_integer, true,
llvm::APFloat::rmNearestTiesToEven);
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
break;
[LLDB][MIPS] Fix offsets of all register sets and add MSA regset and FRE=1 mode support This change : - Fixes offsets of all register sets for Mips. - Adds MSA register set and FRE=1 mode support for FP register set. - Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64. - Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers. - Eliminates ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and uses llvm::APInt and llvm::APFloat for all integer and floating point types. Reviewers : emaste, jaydeep, clayborg Subscribers : emaste, mohit.bhakkad, nitesh.jain, bhushan Differential : http://reviews.llvm.org/D10919 llvm-svn: 244308
2015-08-07 14:39:38 +08:00
}
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_uint256:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (type) {
case e_void:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: jaydeep, clayborg, jasonmolenda, ovyalov, emaste Subscribers: tberghammer, ovyalov, emaste, mohit.bhakkad, nitesh.jain, bhushan Differential: http://reviews.llvm.org/D10919 llvm-svn: 245216
2015-08-17 20:05:31 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_uint256:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
break;
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
m_integer = m_integer.zextOrTrunc(BITWIDTH_INT512);
success = true;
break;
Revert "[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue" Reverting as this commit causes an infinite loop. llvm-svn: 245222
2015-08-17 23:28:05 +08:00
case e_float:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEsingle());
m_float.convertFromAPInt(m_integer, false,
llvm::APFloat::rmNearestTiesToEven);
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
success = true;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(llvm::APFloat::IEEEdouble());
m_float.convertFromAPInt(m_integer, false,
llvm::APFloat::rmNearestTiesToEven);
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
success = true;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
m_float = llvm::APFloat(m_ieee_quad ? llvm::APFloat::IEEEquad()
: llvm::APFloat::x87DoubleExtended());
m_float.convertFromAPInt(m_integer, false,
llvm::APFloat::rmNearestTiesToEven);
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
}
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: jaydeep, clayborg, jasonmolenda, ovyalov, emaste Subscribers: tberghammer, ovyalov, emaste, mohit.bhakkad, nitesh.jain, bhushan Differential: http://reviews.llvm.org/D10919 llvm-svn: 245216
2015-08-17 20:05:31 +08:00
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
lldbassert(false && "unimplemented");
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
switch (type) {
case e_void:
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_uint512:
case e_sint512:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
success = true;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: jaydeep, clayborg, jasonmolenda, ovyalov, emaste Subscribers: tberghammer, ovyalov, emaste, mohit.bhakkad, nitesh.jain, bhushan Differential: http://reviews.llvm.org/D10919 llvm-svn: 245216
2015-08-17 20:05:31 +08:00
case e_double:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
m_float = llvm::APFloat(static_cast<double_t>(m_float.convertToFloat()));
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
success = true;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
case e_long_double: {
bool ignore;
m_float.convert(m_ieee_quad ? llvm::APFloat::IEEEquad()
: llvm::APFloat::x87DoubleExtended(),
llvm::APFloat::rmNearestTiesToEven, &ignore);
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
}
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
break;
case e_double:
switch (type) {
case e_void:
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
break;
case e_double:
success = true;
break;
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
case e_long_double: {
bool ignore;
m_float.convert(m_ieee_quad ? llvm::APFloat::IEEEquad()
: llvm::APFloat::x87DoubleExtended(),
llvm::APFloat::rmNearestTiesToEven, &ignore);
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
}
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
break;
case e_long_double:
switch (type) {
case e_void:
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
case e_double:
break;
case e_long_double:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (success)
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_type = type;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return success;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
const char *Scalar::GetValueTypeAsCString(Scalar::Type type) {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (type) {
case e_void:
return "void";
case e_sint:
return "int";
case e_uint:
return "unsigned int";
case e_slong:
return "long";
case e_ulong:
return "unsigned long";
case e_slonglong:
return "long long";
case e_ulonglong:
return "unsigned long long";
case e_float:
return "float";
case e_double:
return "double";
case e_long_double:
return "long double";
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
return "int128_t";
case e_uint128:
return "uint128_t";
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
return "int256_t";
case e_uint256:
return "uint256_t";
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
return "int512_t";
case e_uint512:
return "uint512_t";
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return "???";
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar::Type
Scalar::GetValueTypeForSignedIntegerWithByteSize(size_t byte_size) {
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
if (byte_size <= sizeof(sint_t))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return e_sint;
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
if (byte_size <= sizeof(slong_t))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return e_slong;
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
if (byte_size <= sizeof(slonglong_t))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return e_slonglong;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
return e_void;
}
Revert "[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue" Reverting as this commit causes an infinite loop. llvm-svn: 245222
2015-08-17 23:28:05 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar::Type
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
Scalar::GetValueTypeForUnsignedIntegerWithByteSize(size_t byte_size) {
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
if (byte_size <= sizeof(uint_t))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return e_uint;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
if (byte_size <= sizeof(ulong_t))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return e_ulong;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
if (byte_size <= sizeof(ulonglong_t))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return e_ulonglong;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
return e_void;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
Scalar::Type Scalar::GetValueTypeForFloatWithByteSize(size_t byte_size) {
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
if (byte_size == sizeof(float_t))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return e_float;
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
if (byte_size == sizeof(double_t))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return e_double;
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
if (byte_size == sizeof(long_double_t))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return e_long_double;
return e_void;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
bool Scalar::MakeSigned() {
bool success = false;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (m_type) {
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
case e_sint:
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
case e_uint:
Fixed signed operations in the IR interpreter. Scalar now can make itself signed if needed. <rdar://problem/13977632> llvm-svn: 182668
2013-05-25 04:36:56 +08:00
m_type = e_sint;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
case e_slong:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
case e_ulong:
Fixed signed operations in the IR interpreter. Scalar now can make itself signed if needed. <rdar://problem/13977632> llvm-svn: 182668
2013-05-25 04:36:56 +08:00
m_type = e_slong;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_slonglong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_ulonglong:
Fixed signed operations in the IR interpreter. Scalar now can make itself signed if needed. <rdar://problem/13977632> llvm-svn: 182668
2013-05-25 04:36:56 +08:00
m_type = e_slonglong;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_uint128:
Fix Scalar::MakeSigned for 128- and 256-bit types. Obvious fix for incorrect result types of the operation. Originally committed as part of (now reverted) r266311. llvm-svn: 266419
2016-04-15 17:15:22 +08:00
m_type = e_sint128;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_uint256:
Fix Scalar::MakeSigned for 128- and 256-bit types. Obvious fix for incorrect result types of the operation. Originally committed as part of (now reverted) r266311. llvm-svn: 266419
2016-04-15 17:15:22 +08:00
m_type = e_sint256;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
success = true;
break;
case e_uint512:
m_type = e_sint512;
success = true;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_float:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
return success;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool Scalar::MakeUnsigned() {
bool success = false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
switch (m_type) {
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
[IRInterpreter] Fix misevaluation of interpretation expressions with `urem`. Scalar::MakeUnsigned was implemented incorrectly so it didn't really change the sign of the type (leaving signed types signed). This showed up as a misevaluation when IR-interpreting urem but it's likely to arise in other contexts. This commit fixes the definition, and adds a test to make sure this won't regress in future (hopefully). Fixes rdar://problem/42038760 and LLVM PR38076 Differential Revision: https://reviews.llvm.org/D49155 llvm-svn: 336872
2018-07-12 08:31:04 +08:00
m_type = e_uint;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_uint:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_slong:
[IRInterpreter] Fix misevaluation of interpretation expressions with `urem`. Scalar::MakeUnsigned was implemented incorrectly so it didn't really change the sign of the type (leaving signed types signed). This showed up as a misevaluation when IR-interpreting urem but it's likely to arise in other contexts. This commit fixes the definition, and adds a test to make sure this won't regress in future (hopefully). Fixes rdar://problem/42038760 and LLVM PR38076 Differential Revision: https://reviews.llvm.org/D49155 llvm-svn: 336872
2018-07-12 08:31:04 +08:00
m_type = e_ulong;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_ulong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_slonglong:
[IRInterpreter] Fix misevaluation of interpretation expressions with `urem`. Scalar::MakeUnsigned was implemented incorrectly so it didn't really change the sign of the type (leaving signed types signed). This showed up as a misevaluation when IR-interpreting urem but it's likely to arise in other contexts. This commit fixes the definition, and adds a test to make sure this won't regress in future (hopefully). Fixes rdar://problem/42038760 and LLVM PR38076 Differential Revision: https://reviews.llvm.org/D49155 llvm-svn: 336872
2018-07-12 08:31:04 +08:00
m_type = e_ulonglong;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_ulonglong:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
[IRInterpreter] Fix misevaluation of interpretation expressions with `urem`. Scalar::MakeUnsigned was implemented incorrectly so it didn't really change the sign of the type (leaving signed types signed). This showed up as a misevaluation when IR-interpreting urem but it's likely to arise in other contexts. This commit fixes the definition, and adds a test to make sure this won't regress in future (hopefully). Fixes rdar://problem/42038760 and LLVM PR38076 Differential Revision: https://reviews.llvm.org/D49155 llvm-svn: 336872
2018-07-12 08:31:04 +08:00
m_type = e_uint128;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_uint128:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
[IRInterpreter] Fix misevaluation of interpretation expressions with `urem`. Scalar::MakeUnsigned was implemented incorrectly so it didn't really change the sign of the type (leaving signed types signed). This showed up as a misevaluation when IR-interpreting urem but it's likely to arise in other contexts. This commit fixes the definition, and adds a test to make sure this won't regress in future (hopefully). Fixes rdar://problem/42038760 and LLVM PR38076 Differential Revision: https://reviews.llvm.org/D49155 llvm-svn: 336872
2018-07-12 08:31:04 +08:00
m_type = e_uint256;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_uint256:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
m_type = e_uint512;
success = true;
break;
case e_uint512:
success = true;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_float:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
success = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
return success;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
signed char Scalar::SChar(char fail_value) const {
switch (m_type) {
case e_void:
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<schar_t>(
(m_integer.sextOrTrunc(sizeof(schar_t) * 8)).getSExtValue());
Revert "[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue" Reverting as this commit causes an infinite loop. llvm-svn: 245222
2015-08-17 23:28:05 +08:00
case e_float:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<schar_t>(m_float.convertToFloat());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<schar_t>(m_float.convertToDouble());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
llvm::APInt ldbl_val = m_float.bitcastToAPInt();
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<schar_t>(
(ldbl_val.sextOrTrunc(sizeof(schar_t) * 8)).getSExtValue());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB][MIPS] Fix offsets of all register sets and add MSA regset and FRE=1 mode support This change : - Fixes offsets of all register sets for Mips. - Adds MSA register set and FRE=1 mode support for FP register set. - Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64. - Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers. - Eliminates ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and uses llvm::APInt and llvm::APFloat for all integer and floating point types. Reviewers : emaste, jaydeep, clayborg Subscribers : emaste, mohit.bhakkad, nitesh.jain, bhushan Differential : http://reviews.llvm.org/D10919 llvm-svn: 244308
2015-08-07 14:39:38 +08:00
return fail_value;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
unsigned char Scalar::UChar(unsigned char fail_value) const {
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
switch (m_type) {
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<uchar_t>(
(m_integer.zextOrTrunc(sizeof(uchar_t) * 8)).getZExtValue());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<uchar_t>(m_float.convertToFloat());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: jaydeep, clayborg, jasonmolenda, ovyalov, emaste Subscribers: tberghammer, ovyalov, emaste, mohit.bhakkad, nitesh.jain, bhushan Differential: http://reviews.llvm.org/D10919 llvm-svn: 245216
2015-08-17 20:05:31 +08:00
case e_double:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<uchar_t>(m_float.convertToDouble());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
llvm::APInt ldbl_val = m_float.bitcastToAPInt();
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<uchar_t>(
(ldbl_val.zextOrTrunc(sizeof(uchar_t) * 8)).getZExtValue());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB][MIPS] Fix offsets of all register sets and add MSA regset and FRE=1 mode support This change : - Fixes offsets of all register sets for Mips. - Adds MSA register set and FRE=1 mode support for FP register set. - Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64. - Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers. - Eliminates ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and uses llvm::APInt and llvm::APFloat for all integer and floating point types. Reviewers : emaste, jaydeep, clayborg Subscribers : emaste, mohit.bhakkad, nitesh.jain, bhushan Differential : http://reviews.llvm.org/D10919 llvm-svn: 244308
2015-08-07 14:39:38 +08:00
return fail_value;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
short Scalar::SShort(short fail_value) const {
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
switch (m_type) {
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<sshort_t>(
(m_integer.sextOrTrunc(sizeof(sshort_t) * 8)).getSExtValue());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<sshort_t>(m_float.convertToFloat());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<sshort_t>(m_float.convertToDouble());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
llvm::APInt ldbl_val = m_float.bitcastToAPInt();
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<sshort_t>(
(ldbl_val.sextOrTrunc(sizeof(sshort_t) * 8)).getSExtValue());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB][MIPS] Fix offsets of all register sets and add MSA regset and FRE=1 mode support This change : - Fixes offsets of all register sets for Mips. - Adds MSA register set and FRE=1 mode support for FP register set. - Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64. - Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers. - Eliminates ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and uses llvm::APInt and llvm::APFloat for all integer and floating point types. Reviewers : emaste, jaydeep, clayborg Subscribers : emaste, mohit.bhakkad, nitesh.jain, bhushan Differential : http://reviews.llvm.org/D10919 llvm-svn: 244308
2015-08-07 14:39:38 +08:00
return fail_value;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
unsigned short Scalar::UShort(unsigned short fail_value) const {
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
switch (m_type) {
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<ushort_t>(
(m_integer.zextOrTrunc(sizeof(ushort_t) * 8)).getZExtValue());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<ushort_t>(m_float.convertToFloat());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<ushort_t>(m_float.convertToDouble());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
llvm::APInt ldbl_val = m_float.bitcastToAPInt();
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<ushort_t>(
(ldbl_val.zextOrTrunc(sizeof(ushort_t) * 8)).getZExtValue());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB][MIPS] Fix offsets of all register sets and add MSA regset and FRE=1 mode support This change : - Fixes offsets of all register sets for Mips. - Adds MSA register set and FRE=1 mode support for FP register set. - Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64. - Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers. - Eliminates ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and uses llvm::APInt and llvm::APFloat for all integer and floating point types. Reviewers : emaste, jaydeep, clayborg Subscribers : emaste, mohit.bhakkad, nitesh.jain, bhushan Differential : http://reviews.llvm.org/D10919 llvm-svn: 244308
2015-08-07 14:39:38 +08:00
return fail_value;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
int Scalar::SInt(int fail_value) const {
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
switch (m_type) {
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<sint_t>(
(m_integer.sextOrTrunc(sizeof(sint_t) * 8)).getSExtValue());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<sint_t>(m_float.convertToFloat());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<sint_t>(m_float.convertToDouble());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: jaydeep, clayborg, jasonmolenda, ovyalov, emaste Subscribers: tberghammer, ovyalov, emaste, mohit.bhakkad, nitesh.jain, bhushan Differential: http://reviews.llvm.org/D10919 llvm-svn: 245216
2015-08-17 20:05:31 +08:00
case e_long_double:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
llvm::APInt ldbl_val = m_float.bitcastToAPInt();
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<sint_t>(
(ldbl_val.sextOrTrunc(sizeof(sint_t) * 8)).getSExtValue());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
return fail_value;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
unsigned int Scalar::UInt(unsigned int fail_value) const {
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
switch (m_type) {
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<uint_t>(
(m_integer.zextOrTrunc(sizeof(uint_t) * 8)).getZExtValue());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<uint_t>(m_float.convertToFloat());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_double:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<uint_t>(m_float.convertToDouble());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_long_double:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
llvm::APInt ldbl_val = m_float.bitcastToAPInt();
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<uint_t>(
(ldbl_val.zextOrTrunc(sizeof(uint_t) * 8)).getZExtValue());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB][MIPS] Fix offsets of all register sets and add MSA regset and FRE=1 mode support This change : - Fixes offsets of all register sets for Mips. - Adds MSA register set and FRE=1 mode support for FP register set. - Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64. - Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers. - Eliminates ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and uses llvm::APInt and llvm::APFloat for all integer and floating point types. Reviewers : emaste, jaydeep, clayborg Subscribers : emaste, mohit.bhakkad, nitesh.jain, bhushan Differential : http://reviews.llvm.org/D10919 llvm-svn: 244308
2015-08-07 14:39:38 +08:00
return fail_value;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
long Scalar::SLong(long fail_value) const {
switch (m_type) {
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_void:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<slong_t>(
(m_integer.sextOrTrunc(sizeof(slong_t) * 8)).getSExtValue());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<slong_t>(m_float.convertToFloat());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<slong_t>(m_float.convertToDouble());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
llvm::APInt ldbl_val = m_float.bitcastToAPInt();
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<slong_t>(
(ldbl_val.sextOrTrunc(sizeof(slong_t) * 8)).getSExtValue());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB][MIPS] Fix offsets of all register sets and add MSA regset and FRE=1 mode support This change : - Fixes offsets of all register sets for Mips. - Adds MSA register set and FRE=1 mode support for FP register set. - Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64. - Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers. - Eliminates ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and uses llvm::APInt and llvm::APFloat for all integer and floating point types. Reviewers : emaste, jaydeep, clayborg Subscribers : emaste, mohit.bhakkad, nitesh.jain, bhushan Differential : http://reviews.llvm.org/D10919 llvm-svn: 244308
2015-08-07 14:39:38 +08:00
return fail_value;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
unsigned long Scalar::ULong(unsigned long fail_value) const {
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
switch (m_type) {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<ulong_t>(
(m_integer.zextOrTrunc(sizeof(ulong_t) * 8)).getZExtValue());
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_float:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<ulong_t>(m_float.convertToFloat());
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_double:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<ulong_t>(m_float.convertToDouble());
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_long_double:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
llvm::APInt ldbl_val = m_float.bitcastToAPInt();
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<ulong_t>(
(ldbl_val.zextOrTrunc(sizeof(ulong_t) * 8)).getZExtValue());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB][MIPS] Fix offsets of all register sets and add MSA regset and FRE=1 mode support This change : - Fixes offsets of all register sets for Mips. - Adds MSA register set and FRE=1 mode support for FP register set. - Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64. - Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers. - Eliminates ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and uses llvm::APInt and llvm::APFloat for all integer and floating point types. Reviewers : emaste, jaydeep, clayborg Subscribers : emaste, mohit.bhakkad, nitesh.jain, bhushan Differential : http://reviews.llvm.org/D10919 llvm-svn: 244308
2015-08-07 14:39:38 +08:00
return fail_value;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
long long Scalar::SLongLong(long long fail_value) const {
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
switch (m_type) {
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<slonglong_t>(
(m_integer.sextOrTrunc(sizeof(slonglong_t) * 8)).getSExtValue());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<slonglong_t>(m_float.convertToFloat());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<slonglong_t>(m_float.convertToDouble());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
llvm::APInt ldbl_val = m_float.bitcastToAPInt();
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<slonglong_t>(
(ldbl_val.sextOrTrunc(sizeof(slonglong_t) * 8)).getSExtValue());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
return fail_value;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
unsigned long long Scalar::ULongLong(unsigned long long fail_value) const {
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
switch (m_type) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<ulonglong_t>(
(m_integer.zextOrTrunc(sizeof(ulonglong_t) * 8)).getZExtValue());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<ulonglong_t>(m_float.convertToFloat());
[Scalar] Commit the correct patch, forgot `git add`. <rdar://problem/44229924> llvm-svn: 341685
2018-09-08 02:22:27 +08:00
case e_double: {
double d_val = m_float.convertToDouble();
llvm::APInt rounded_double =
llvm::APIntOps::RoundDoubleToAPInt(d_val, sizeof(ulonglong_t) * 8);
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<ulonglong_t>(
(rounded_double.zextOrTrunc(sizeof(ulonglong_t) * 8)).getZExtValue());
[Scalar] Commit the correct patch, forgot `git add`. <rdar://problem/44229924> llvm-svn: 341685
2018-09-08 02:22:27 +08:00
}
case e_long_double:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
llvm::APInt ldbl_val = m_float.bitcastToAPInt();
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<ulonglong_t>(
(ldbl_val.zextOrTrunc(sizeof(ulonglong_t) * 8)).getZExtValue());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
return fail_value;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
llvm::APInt Scalar::SInt128(llvm::APInt &fail_value) const {
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
switch (m_type) {
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
return m_integer;
case e_float:
case e_double:
case e_long_double:
return m_float.bitcastToAPInt();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
return fail_value;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
llvm::APInt Scalar::UInt128(const llvm::APInt &fail_value) const {
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
switch (m_type) {
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
return m_integer;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
case e_double:
case e_long_double:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
return m_float.bitcastToAPInt();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return fail_value;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
float Scalar::Float(float fail_value) const {
switch (m_type) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
return llvm::APIntOps::RoundAPIntToFloat(m_integer);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
return m_float.convertToFloat();
case e_double:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<float_t>(m_float.convertToDouble());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
llvm::APInt ldbl_val = m_float.bitcastToAPInt();
return ldbl_val.bitsToFloat();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
return fail_value;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
double Scalar::Double(double fail_value) const {
switch (m_type) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[Core] Grab-bag of improvements for Scalar. Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
2018-04-03 00:50:54 +08:00
return llvm::APIntOps::RoundAPIntToDouble(m_integer);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<double_t>(m_float.convertToFloat());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
return m_float.convertToDouble();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_long_double:
llvm::APInt ldbl_val = m_float.bitcastToAPInt();
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
return ldbl_val.bitsToFloat();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return fail_value;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
long double Scalar::LongDouble(long double fail_value) const {
switch (m_type) {
case e_void:
break;
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<long_double_t>(
llvm::APIntOps::RoundAPIntToDouble(m_integer));
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<long_double_t>(m_float.convertToFloat());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_double:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<long_double_t>(m_float.convertToDouble());
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_long_double:
llvm::APInt ldbl_val = m_float.bitcastToAPInt();
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
return static_cast<long_double_t>(ldbl_val.bitsToDouble());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return fail_value;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar &Scalar::operator+=(const Scalar &rhs) {
Scalar temp_value;
const Scalar *a;
const Scalar *b;
if ((m_type = PromoteToMaxType(*this, rhs, temp_value, a, b)) !=
Scalar::e_void) {
switch (m_type) {
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer = a->m_integer + b->m_integer;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_float:
case e_double:
case e_long_double:
m_float = a->m_float + b->m_float;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return *this;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar &Scalar::operator<<=(const Scalar &rhs) {
switch (m_type) {
case e_void:
case e_float:
case e_double:
case e_long_double:
m_type = e_void;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (rhs.m_type) {
case e_void:
case e_float:
case e_double:
case e_long_double:
m_type = e_void;
break;
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_integer = m_integer << rhs.m_integer;
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return *this;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool Scalar::ShiftRightLogical(const Scalar &rhs) {
switch (m_type) {
case e_void:
case e_float:
[LLDB][MIPS] Fix offsets of all register sets and add MSA regset and FRE=1 mode support This change : - Fixes offsets of all register sets for Mips. - Adds MSA register set and FRE=1 mode support for FP register set. - Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64. - Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers. - Eliminates ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and uses llvm::APInt and llvm::APFloat for all integer and floating point types. Reviewers : emaste, jaydeep, clayborg Subscribers : emaste, mohit.bhakkad, nitesh.jain, bhushan Differential : http://reviews.llvm.org/D10919 llvm-svn: 244308
2015-08-07 14:39:38 +08:00
case e_double:
case e_long_double:
m_type = e_void;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Revert r244308 since it's introducing test regressions on Linux: - TestLldbGdbServer.py both clang & gcc, i386 and x86_64 - TestConstVariables.py gcc, i386 and x86_64 - 112 failures clang, i386 llvm-svn: 244514
2015-08-11 05:49:50 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (rhs.m_type) {
case e_void:
case e_float:
[LLDB][MIPS] Fix offsets of all register sets and add MSA regset and FRE=1 mode support This change : - Fixes offsets of all register sets for Mips. - Adds MSA register set and FRE=1 mode support for FP register set. - Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64. - Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers. - Eliminates ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and uses llvm::APInt and llvm::APFloat for all integer and floating point types. Reviewers : emaste, jaydeep, clayborg Subscribers : emaste, mohit.bhakkad, nitesh.jain, bhushan Differential : http://reviews.llvm.org/D10919 llvm-svn: 244308
2015-08-07 14:39:38 +08:00
case e_double:
case e_long_double:
m_type = e_void;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
Revert r244308 since it's introducing test regressions on Linux: - TestLldbGdbServer.py both clang & gcc, i386 and x86_64 - TestConstVariables.py gcc, i386 and x86_64 - 112 failures clang, i386 llvm-svn: 244514
2015-08-11 05:49:50 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
Revert r244308 since it's introducing test regressions on Linux: - TestLldbGdbServer.py both clang & gcc, i386 and x86_64 - TestConstVariables.py gcc, i386 and x86_64 - 112 failures clang, i386 llvm-svn: 244514
2015-08-11 05:49:50 +08:00
m_integer = m_integer.lshr(rhs.m_integer);
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 263312
2016-03-12 08:31:13 +08:00
break;
Revert r244308 since it's introducing test regressions on Linux: - TestLldbGdbServer.py both clang & gcc, i386 and x86_64 - TestConstVariables.py gcc, i386 and x86_64 - 112 failures clang, i386 llvm-svn: 244514
2015-08-11 05:49:50 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
Revert r244308 since it's introducing test regressions on Linux: - TestLldbGdbServer.py both clang & gcc, i386 and x86_64 - TestConstVariables.py gcc, i386 and x86_64 - 112 failures clang, i386 llvm-svn: 244514
2015-08-11 05:49:50 +08:00
return m_type != e_void;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Revert r244308 since it's introducing test regressions on Linux: - TestLldbGdbServer.py both clang & gcc, i386 and x86_64 - TestConstVariables.py gcc, i386 and x86_64 - 112 failures clang, i386 llvm-svn: 244514
2015-08-11 05:49:50 +08:00
Scalar &Scalar::operator>>=(const Scalar &rhs) {
switch (m_type) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_void:
case e_float:
case e_double:
case e_long_double:
m_type = e_void;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_ulonglong:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
switch (rhs.m_type) {
case e_void:
case e_float:
case e_double:
case e_long_double:
m_type = e_void;
Revert "[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue" Reverting as this commit causes an infinite loop. llvm-svn: 245222
2015-08-17 23:28:05 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_ulonglong:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_integer = m_integer.ashr(rhs.m_integer);
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 263312
2016-03-12 08:31:13 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return *this;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar &Scalar::operator&=(const Scalar &rhs) {
switch (m_type) {
case e_void:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
case e_double:
case e_long_double:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_type = e_void;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (rhs.m_type) {
case e_void:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_float:
case e_double:
case e_long_double:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_type = e_void;
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer &= rhs.m_integer;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
break;
}
return *this;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool Scalar::AbsoluteValue() {
switch (m_type) {
Fixed a missing break and fixed spacing. llvm-svn: 268562
2016-05-05 06:14:55 +08:00
case e_void:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_slong:
case e_slonglong:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint128:
Added a SetData() method to ValueObject. This lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). llvm-svn: 179437
2013-04-13 09:21:23 +08:00
case e_sint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
Fix Windows build using portable types for formatting the log outputs llvm-svn: 202723
2014-03-03 23:39:47 +08:00
if (m_integer.isNegative())
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer = -m_integer;
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
return true;
<rdar://problem/10546739> Fixed SBValue::GetValueAsUnsigned() and SBValue::GetValueAsSigned() calls to work for bitfields. llvm-svn: 147332
2011-12-29 09:26:56 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_uint:
case e_ulong:
case e_ulonglong:
return true;
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_uint512:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_float:
case e_double:
case e_long_double:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_float.clearSign();
return true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool Scalar::UnaryNegate() {
<rdar://problem/10546739> Fixed SBValue::GetValueAsUnsigned() and SBValue::GetValueAsSigned() calls to work for bitfields. llvm-svn: 147332
2011-12-29 09:26:56 +08:00
switch (m_type) {
case e_void:
break;
case e_sint:
Revert "[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue" Reverting as this commit causes an infinite loop. llvm-svn: 245222
2015-08-17 23:28:05 +08:00
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_ulonglong:
case e_sint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_uint128:
case e_sint256:
Avoid an assertion failure when a bit field is extracted from a value of the same size. Summary: One of the cases handled by ValueObjectChild::UpdateValue() uses the entire width of the parent's scalar value as the size of the child, and extracts the child by calling Scalar::ExtractBitfield(). This seems valid but APInt::trunc(), APInt::sext() and APInt::zext() assert that the bit field must not have the same size as the parent scalar. Replacing those calls with sextOrTrunc(), zextOrTrunc(), sextOrSelf() and zextOrSelf() fixes the assertion failures. Reviewers: uweigand, labath Subscribers: labath, lldb-commits Differential Revision: http://reviews.llvm.org/D20355 llvm-svn: 270062
2016-05-19 21:51:20 +08:00
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
Avoid an assertion failure when a bit field is extracted from a value of the same size. Summary: One of the cases handled by ValueObjectChild::UpdateValue() uses the entire width of the parent's scalar value as the size of the child, and extracts the child by calling Scalar::ExtractBitfield(). This seems valid but APInt::trunc(), APInt::sext() and APInt::zext() assert that the bit field must not have the same size as the parent scalar. Replacing those calls with sextOrTrunc(), zextOrTrunc(), sextOrSelf() and zextOrSelf() fixes the assertion failures. Reviewers: uweigand, labath Subscribers: labath, lldb-commits Differential Revision: http://reviews.llvm.org/D20355 llvm-svn: 270062
2016-05-19 21:51:20 +08:00
m_integer = -m_integer;
Revert "[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue" Reverting as this commit causes an infinite loop. llvm-svn: 245222
2015-08-17 23:28:05 +08:00
return true;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_float:
case e_double:
case e_long_double:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_float.changeSign();
return true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
bool Scalar::OnesComplement() {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (m_type) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
<rdar://problem/10546739> Fixed SBValue::GetValueAsUnsigned() and SBValue::GetValueAsSigned() calls to work for bitfields. llvm-svn: 147332
2011-12-29 09:26:56 +08:00
case e_slonglong:
case e_ulonglong:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint128:
case e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
Avoid an assertion failure when a bit field is extracted from a value of the same size. Summary: One of the cases handled by ValueObjectChild::UpdateValue() uses the entire width of the parent's scalar value as the size of the child, and extracts the child by calling Scalar::ExtractBitfield(). This seems valid but APInt::trunc(), APInt::sext() and APInt::zext() assert that the bit field must not have the same size as the parent scalar. Replacing those calls with sextOrTrunc(), zextOrTrunc(), sextOrSelf() and zextOrSelf() fixes the assertion failures. Reviewers: uweigand, labath Subscribers: labath, lldb-commits Differential Revision: http://reviews.llvm.org/D20355 llvm-svn: 270062
2016-05-19 21:51:20 +08:00
m_integer = ~m_integer;
<rdar://problem/10546739> Fixed SBValue::GetValueAsUnsigned() and SBValue::GetValueAsSigned() calls to work for bitfields. llvm-svn: 147332
2011-12-29 09:26:56 +08:00
return true;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case e_void:
case e_float:
case e_double:
case e_long_double:
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
const Scalar lldb_private::operator+(const Scalar &lhs, const Scalar &rhs) {
Scalar result;
Scalar temp_value;
const Scalar *a;
const Scalar *b;
if ((result.m_type = PromoteToMaxType(lhs, rhs, temp_value, a, b)) !=
Scalar::e_void) {
switch (result.m_type) {
case Scalar::e_void:
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_sint:
case Scalar::e_uint:
case Scalar::e_slong:
case Scalar::e_ulong:
case Scalar::e_slonglong:
case Scalar::e_ulonglong:
case Scalar::e_sint128:
case Scalar::e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case Scalar::e_sint256:
case Scalar::e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case Scalar::e_sint512:
case Scalar::e_uint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
result.m_integer = a->m_integer + b->m_integer;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_float:
case Scalar::e_double:
case Scalar::e_long_double:
result.m_float = a->m_float + b->m_float;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return result;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
const Scalar lldb_private::operator-(const Scalar &lhs, const Scalar &rhs) {
Scalar result;
Scalar temp_value;
const Scalar *a;
const Scalar *b;
if ((result.m_type = PromoteToMaxType(lhs, rhs, temp_value, a, b)) !=
Scalar::e_void) {
switch (result.m_type) {
case Scalar::e_void:
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_sint:
case Scalar::e_uint:
case Scalar::e_slong:
case Scalar::e_ulong:
case Scalar::e_slonglong:
case Scalar::e_ulonglong:
case Scalar::e_sint128:
case Scalar::e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case Scalar::e_sint256:
case Scalar::e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case Scalar::e_sint512:
case Scalar::e_uint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
result.m_integer = a->m_integer - b->m_integer;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_float:
case Scalar::e_double:
case Scalar::e_long_double:
result.m_float = a->m_float - b->m_float;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return result;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
const Scalar lldb_private::operator/(const Scalar &lhs, const Scalar &rhs) {
Scalar result;
Scalar temp_value;
const Scalar *a;
const Scalar *b;
if ((result.m_type = PromoteToMaxType(lhs, rhs, temp_value, a, b)) !=
Scalar::e_void) {
switch (result.m_type) {
case Scalar::e_void:
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_sint:
case Scalar::e_slong:
case Scalar::e_slonglong:
case Scalar::e_sint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case Scalar::e_sint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case Scalar::e_sint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
if (b->m_integer != 0) {
result.m_integer = a->m_integer.sdiv(b->m_integer);
return result;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_uint:
case Scalar::e_ulong:
case Scalar::e_ulonglong:
case Scalar::e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case Scalar::e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case Scalar::e_uint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
if (b->m_integer != 0) {
result.m_integer = a->m_integer.udiv(b->m_integer);
return result;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_float:
case Scalar::e_double:
case Scalar::e_long_double:
[Core] Correctly handle float division in Scalar. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44693 llvm-svn: 328649
2018-03-28 02:37:54 +08:00
if (!b->m_float.isZero()) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
result.m_float = a->m_float / b->m_float;
return result;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// For division only, the only way it should make it here is if a promotion
Reflow paragraphs in comments. 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
2018-05-01 00:49:04 +08:00
// failed, or if we are trying to do a divide by zero.
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
result.m_type = Scalar::e_void;
return result;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
const Scalar lldb_private::operator*(const Scalar &lhs, const Scalar &rhs) {
Scalar result;
Scalar temp_value;
const Scalar *a;
const Scalar *b;
if ((result.m_type = PromoteToMaxType(lhs, rhs, temp_value, a, b)) !=
Scalar::e_void) {
switch (result.m_type) {
case Scalar::e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_sint:
case Scalar::e_uint:
case Scalar::e_slong:
case Scalar::e_ulong:
case Scalar::e_slonglong:
case Scalar::e_ulonglong:
case Scalar::e_sint128:
case Scalar::e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case Scalar::e_sint256:
case Scalar::e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case Scalar::e_sint512:
case Scalar::e_uint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
result.m_integer = a->m_integer * b->m_integer;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case Scalar::e_float:
case Scalar::e_double:
case Scalar::e_long_double:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
result.m_float = a->m_float * b->m_float;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return result;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
const Scalar lldb_private::operator&(const Scalar &lhs, const Scalar &rhs) {
Scalar result;
Scalar temp_value;
const Scalar *a;
const Scalar *b;
if ((result.m_type = PromoteToMaxType(lhs, rhs, temp_value, a, b)) !=
Scalar::e_void) {
switch (result.m_type) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_sint:
case Scalar::e_uint:
case Scalar::e_slong:
case Scalar::e_ulong:
case Scalar::e_slonglong:
case Scalar::e_ulonglong:
case Scalar::e_sint128:
case Scalar::e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case Scalar::e_sint256:
case Scalar::e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case Scalar::e_sint512:
case Scalar::e_uint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
result.m_integer = a->m_integer & b->m_integer;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case Scalar::e_void:
case Scalar::e_float:
case Scalar::e_double:
case Scalar::e_long_double:
// No bitwise AND on floats, doubles of long doubles
result.m_type = Scalar::e_void;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return result;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Added emulation of shifts to the IR interpreter. <rdar://problem/12978619> llvm-svn: 172013
2013-01-10 06:44:41 +08:00
const Scalar lldb_private::operator|(const Scalar &lhs, const Scalar &rhs) {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar result;
Scalar temp_value;
const Scalar *a;
const Scalar *b;
if ((result.m_type = PromoteToMaxType(lhs, rhs, temp_value, a, b)) !=
Scalar::e_void) {
switch (result.m_type) {
case Scalar::e_sint:
Fixed a missing break and fixed spacing. llvm-svn: 268562
2016-05-05 06:14:55 +08:00
case Scalar::e_uint:
case Scalar::e_slong:
case Scalar::e_ulong:
case Scalar::e_slonglong:
case Scalar::e_ulonglong:
case Scalar::e_sint128:
case Scalar::e_uint128:
case Scalar::e_sint256:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case Scalar::e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case Scalar::e_sint512:
case Scalar::e_uint512:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
result.m_integer = a->m_integer | b->m_integer;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Fixed a missing break and fixed spacing. llvm-svn: 268562
2016-05-05 06:14:55 +08:00
case Scalar::e_void:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case Scalar::e_float:
case Scalar::e_double:
case Scalar::e_long_double:
// No bitwise AND on floats, doubles of long doubles
Check for division by zero when performing modulus operations. <rdar://problem/14656908> llvm-svn: 187996
2013-08-09 01:57:00 +08:00
result.m_type = Scalar::e_void;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
}
Fixed a missing break and fixed spacing. llvm-svn: 268562
2016-05-05 06:14:55 +08:00
return result;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Added emulation of shifts to the IR interpreter. <rdar://problem/12978619> llvm-svn: 172013
2013-01-10 06:44:41 +08:00
const Scalar lldb_private::operator%(const Scalar &lhs, const Scalar &rhs) {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar result;
Scalar temp_value;
const Scalar *a;
const Scalar *b;
if ((result.m_type = PromoteToMaxType(lhs, rhs, temp_value, a, b)) !=
Scalar::e_void) {
switch (result.m_type) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
default:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
case Scalar::e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_sint:
case Scalar::e_slong:
case Scalar::e_slonglong:
case Scalar::e_sint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case Scalar::e_sint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case Scalar::e_sint512:
Fixed a missing break and fixed spacing. llvm-svn: 268562
2016-05-05 06:14:55 +08:00
if (b->m_integer != 0) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
result.m_integer = a->m_integer.srem(b->m_integer);
return result;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_uint:
case Scalar::e_ulong:
case Scalar::e_ulonglong:
case Scalar::e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case Scalar::e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case Scalar::e_uint512:
Fixed a missing break and fixed spacing. llvm-svn: 268562
2016-05-05 06:14:55 +08:00
if (b->m_integer != 0) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
result.m_integer = a->m_integer.urem(b->m_integer);
return result;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
break;
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
result.m_type = Scalar::e_void;
return result;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Added emulation of shifts to the IR interpreter. <rdar://problem/12978619> llvm-svn: 172013
2013-01-10 06:44:41 +08:00
const Scalar lldb_private::operator^(const Scalar &lhs, const Scalar &rhs) {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar result;
Scalar temp_value;
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
const Scalar *a;
const Scalar *b;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
if ((result.m_type = PromoteToMaxType(lhs, rhs, temp_value, a, b)) !=
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar::e_void) {
switch (result.m_type) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_sint:
case Scalar::e_uint:
case Scalar::e_slong:
case Scalar::e_ulong:
case Scalar::e_slonglong:
case Scalar::e_ulonglong:
case Scalar::e_sint128:
case Scalar::e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case Scalar::e_sint256:
case Scalar::e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case Scalar::e_sint512:
case Scalar::e_uint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
result.m_integer = a->m_integer ^ b->m_integer;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case Scalar::e_void:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_float:
case Scalar::e_double:
case Scalar::e_long_double:
// No bitwise AND on floats, doubles of long doubles
result.m_type = Scalar::e_void;
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return result;
}
const Scalar lldb_private::operator<<(const Scalar &lhs, const Scalar &rhs) {
Scalar result = lhs;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
result <<= rhs;
return result;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
const Scalar lldb_private::operator>>(const Scalar &lhs, const Scalar &rhs) {
Scalar result = lhs;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
result >>= rhs;
return result;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
Status Scalar::SetValueFromCString(const char *value_str, Encoding encoding,
size_t byte_size) {
Status error;
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 263312
2016-03-12 08:31:13 +08:00
if (value_str == nullptr || value_str[0] == '\0') {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
error.SetErrorString("Invalid c-string value string.");
return error;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
switch (encoding) {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eEncodingInvalid:
error.SetErrorString("Invalid encoding.");
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
break;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eEncodingUint:
Scalar: Use llvm integer conversion functions StringConvert was the only non-Utility dependency of this class. Getting rid of it means it will be easy to move this class to a lower layer. While I was in there, I also added a couple of unit tests for the Scalar string conversion function. llvm-svn: 335060
2018-06-20 01:24:03 +08:00
if (byte_size <= sizeof(uint64_t)) {
uint64_t uval64;
if (!llvm::to_integer(value_str, uval64))
Fix Windows build using portable types for formatting the log outputs llvm-svn: 202723
2014-03-03 23:39:47 +08:00
error.SetErrorStringWithFormat(
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
"'%s' is not a valid unsigned integer string value", value_str);
else if (!UIntValueIsValidForSize(uval64, byte_size))
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
error.SetErrorStringWithFormat(
"value 0x%" PRIx64 " is too large to fit in a %" PRIu64
" byte unsigned integer value",
uval64, static_cast<uint64_t>(byte_size));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
else {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_type = Scalar::GetValueTypeForUnsignedIntegerWithByteSize(byte_size);
switch (m_type) {
case e_uint:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
m_integer = llvm::APInt(sizeof(uint_t) * 8, uval64, false);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_ulong:
m_integer = llvm::APInt(sizeof(ulong_t) * 8, uval64, false);
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
break;
case e_ulonglong:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer = llvm::APInt(sizeof(ulonglong_t) * 8, uval64, false);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
default:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
error.SetErrorStringWithFormat(
Fix Windows build using portable types for formatting the log outputs llvm-svn: 202723
2014-03-03 23:39:47 +08:00
"unsupported unsigned integer byte size: %" PRIu64 "",
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
static_cast<uint64_t>(byte_size));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
}
} else {
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
error.SetErrorStringWithFormat(
Fix Windows build using portable types for formatting the log outputs llvm-svn: 202723
2014-03-03 23:39:47 +08:00
"unsupported unsigned integer byte size: %" PRIu64 "",
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
static_cast<uint64_t>(byte_size));
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
return error;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eEncodingSint:
Scalar: Use llvm integer conversion functions StringConvert was the only non-Utility dependency of this class. Getting rid of it means it will be easy to move this class to a lower layer. While I was in there, I also added a couple of unit tests for the Scalar string conversion function. llvm-svn: 335060
2018-06-20 01:24:03 +08:00
if (byte_size <= sizeof(int64_t)) {
int64_t sval64;
if (!llvm::to_integer(value_str, sval64))
Fix Windows build using portable types for formatting the log outputs llvm-svn: 202723
2014-03-03 23:39:47 +08:00
error.SetErrorStringWithFormat(
Cleaned up many error codes. For any who is filling in error strings into lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
2011-10-26 08:56:27 +08:00
"'%s' is not a valid signed integer string value", value_str);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
else if (!SIntValueIsValidForSize(sval64, byte_size))
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
error.SetErrorStringWithFormat(
"value 0x%" PRIx64 " is too large to fit in a %" PRIu64
" byte signed integer value",
sval64, static_cast<uint64_t>(byte_size));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
else {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_type = Scalar::GetValueTypeForSignedIntegerWithByteSize(byte_size);
switch (m_type) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
m_integer = llvm::APInt(sizeof(sint_t) * 8, sval64, true);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_slong:
m_integer = llvm::APInt(sizeof(slong_t) * 8, sval64, true);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_slonglong:
m_integer = llvm::APInt(sizeof(slonglong_t) * 8, sval64, true);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
default:
Fix Windows build using portable types for formatting the log outputs llvm-svn: 202723
2014-03-03 23:39:47 +08:00
error.SetErrorStringWithFormat(
"unsupported signed integer byte size: %" PRIu64 "",
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
static_cast<uint64_t>(byte_size));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
}
} else {
Fix Windows build using portable types for formatting the log outputs llvm-svn: 202723
2014-03-03 23:39:47 +08:00
error.SetErrorStringWithFormat(
"unsupported signed integer byte size: %" PRIu64 "",
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
static_cast<uint64_t>(byte_size));
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
return error;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eEncodingIEEE754:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
static float f_val;
static double d_val;
static long double l_val;
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
if (byte_size == sizeof(float)) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
if (::sscanf(value_str, "%f", &f_val) == 1) {
m_float = llvm::APFloat(f_val);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_type = e_float;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else
Cleaned up many error codes. For any who is filling in error strings into lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
2011-10-26 08:56:27 +08:00
error.SetErrorStringWithFormat("'%s' is not a valid float string value",
value_str);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
} else if (byte_size == sizeof(double)) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
if (::sscanf(value_str, "%lf", &d_val) == 1) {
m_float = llvm::APFloat(d_val);
m_type = e_double;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else
Cleaned up many error codes. For any who is filling in error strings into lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
2011-10-26 08:56:27 +08:00
error.SetErrorStringWithFormat("'%s' is not a valid float string value",
value_str);
Added a SetData() method to ValueObject. This lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). llvm-svn: 179437
2013-04-13 09:21:23 +08:00
} else if (byte_size == sizeof(long double)) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
if (::sscanf(value_str, "%Lf", &l_val) == 1) {
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
m_float = llvm::APFloat(
llvm::APFloat::x87DoubleExtended(),
llvm::APInt(BITWIDTH_INT128, NUM_OF_WORDS_INT128,
(reinterpret_cast<type128 *>(&l_val))->x));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_type = e_long_double;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else
Cleaned up many error codes. For any who is filling in error strings into lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
2011-10-26 08:56:27 +08:00
error.SetErrorStringWithFormat("'%s' is not a valid float string value",
value_str);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else {
Fix Windows build using portable types for formatting the log outputs llvm-svn: 202723
2014-03-03 23:39:47 +08:00
error.SetErrorStringWithFormat("unsupported float byte size: %" PRIu64 "",
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
static_cast<uint64_t>(byte_size));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return error;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
case eEncodingVector:
Cleaned up many error codes. For any who is filling in error strings into lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
2011-10-26 08:56:27 +08:00
error.SetErrorString("vector encoding unsupported.");
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (error.Fail())
m_type = e_void;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return error;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
Status Scalar::SetValueFromData(DataExtractor &data, lldb::Encoding encoding,
size_t byte_size) {
Status error;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
type128 int128;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
type256 int256;
Added a SetData() method to ValueObject. This lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). llvm-svn: 179437
2013-04-13 09:21:23 +08:00
switch (encoding) {
case lldb::eEncodingInvalid:
error.SetErrorString("invalid encoding");
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Added a SetData() method to ValueObject. This lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). llvm-svn: 179437
2013-04-13 09:21:23 +08:00
case lldb::eEncodingVector:
error.SetErrorString("vector encoding unsupported");
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
Added a SetData() method to ValueObject. This lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). llvm-svn: 179437
2013-04-13 09:21:23 +08:00
case lldb::eEncodingUint: {
Initialize 3 variables which were being used un-initialized. No regression on testsuite. Comitted as obvious. llvm-svn: 238761
2015-06-02 01:08:30 +08:00
lldb::offset_t offset = 0;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Added a SetData() method to ValueObject. This lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). llvm-svn: 179437
2013-04-13 09:21:23 +08:00
switch (byte_size) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
case 1:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
operator=(data.GetU8(&offset));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case 2:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
operator=(data.GetU16(&offset));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case 4:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
operator=(data.GetU32(&offset));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case 8:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
operator=(data.GetU64(&offset));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case 16:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
if (data.GetByteOrder() == eByteOrderBig) {
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
int128.x[1] = data.GetU64(&offset);
int128.x[0] = data.GetU64(&offset);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else {
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
int128.x[0] = data.GetU64(&offset);
int128.x[1] = data.GetU64(&offset);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
operator=(llvm::APInt(BITWIDTH_INT128, NUM_OF_WORDS_INT128, int128.x));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case 32:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
if (data.GetByteOrder() == eByteOrderBig) {
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
int256.x[3] = data.GetU64(&offset);
int256.x[2] = data.GetU64(&offset);
int256.x[1] = data.GetU64(&offset);
int256.x[0] = data.GetU64(&offset);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else {
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
int256.x[0] = data.GetU64(&offset);
int256.x[1] = data.GetU64(&offset);
int256.x[2] = data.GetU64(&offset);
int256.x[3] = data.GetU64(&offset);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
operator=(llvm::APInt(BITWIDTH_INT256, NUM_OF_WORDS_INT256, int256.x));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
default:
Fix Windows build using portable types for formatting the log outputs llvm-svn: 202723
2014-03-03 23:39:47 +08:00
error.SetErrorStringWithFormat(
"unsupported unsigned integer byte size: %" PRIu64 "",
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
static_cast<uint64_t>(byte_size));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
} break;
Added a SetData() method to ValueObject. This lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). llvm-svn: 179437
2013-04-13 09:21:23 +08:00
case lldb::eEncodingSint: {
Initialize 3 variables which were being used un-initialized. No regression on testsuite. Comitted as obvious. llvm-svn: 238761
2015-06-02 01:08:30 +08:00
lldb::offset_t offset = 0;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Added a SetData() method to ValueObject. This lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). llvm-svn: 179437
2013-04-13 09:21:23 +08:00
switch (byte_size) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
case 1:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
operator=(static_cast<int8_t>(data.GetU8(&offset)));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case 2:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
operator=(static_cast<int16_t>(data.GetU16(&offset)));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case 4:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
operator=(static_cast<int32_t>(data.GetU32(&offset)));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case 8:
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
operator=(static_cast<int64_t>(data.GetU64(&offset)));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case 16:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
if (data.GetByteOrder() == eByteOrderBig) {
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
int128.x[1] = data.GetU64(&offset);
int128.x[0] = data.GetU64(&offset);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else {
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
int128.x[0] = data.GetU64(&offset);
int128.x[1] = data.GetU64(&offset);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
operator=(llvm::APInt(BITWIDTH_INT128, NUM_OF_WORDS_INT128, int128.x));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case 32:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
if (data.GetByteOrder() == eByteOrderBig) {
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
int256.x[3] = data.GetU64(&offset);
int256.x[2] = data.GetU64(&offset);
int256.x[1] = data.GetU64(&offset);
int256.x[0] = data.GetU64(&offset);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else {
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
int256.x[0] = data.GetU64(&offset);
int256.x[1] = data.GetU64(&offset);
int256.x[2] = data.GetU64(&offset);
int256.x[3] = data.GetU64(&offset);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
operator=(llvm::APInt(BITWIDTH_INT256, NUM_OF_WORDS_INT256, int256.x));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
default:
Fix Windows build using portable types for formatting the log outputs llvm-svn: 202723
2014-03-03 23:39:47 +08:00
error.SetErrorStringWithFormat(
"unsupported signed integer byte size: %" PRIu64 "",
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
static_cast<uint64_t>(byte_size));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
} break;
Added a SetData() method to ValueObject. This lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). llvm-svn: 179437
2013-04-13 09:21:23 +08:00
case lldb::eEncodingIEEE754: {
Initialize 3 variables which were being used un-initialized. No regression on testsuite. Comitted as obvious. llvm-svn: 238761
2015-06-02 01:08:30 +08:00
lldb::offset_t offset = 0;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
if (byte_size == sizeof(float))
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
operator=(data.GetFloat(&offset));
Added a SetData() method to ValueObject. This lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). llvm-svn: 179437
2013-04-13 09:21:23 +08:00
else if (byte_size == sizeof(double))
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
operator=(data.GetDouble(&offset));
Added a SetData() method to ValueObject. This lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). llvm-svn: 179437
2013-04-13 09:21:23 +08:00
else if (byte_size == sizeof(long double))
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
operator=(data.GetLongDouble(&offset));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
else
Fix Windows build using portable types for formatting the log outputs llvm-svn: 202723
2014-03-03 23:39:47 +08:00
error.SetErrorStringWithFormat("unsupported float byte size: %" PRIu64 "",
[Utility] Modernize C-style cats Replaces the remaining C-style casts with explicit casts in Utility. The motivation is that they are (1) easier to spot and (2) don't have multiple meanings. llvm-svn: 361458
2019-05-23 13:12:11 +08:00
static_cast<uint64_t>(byte_size));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} break;
}
Added a SetData() method to ValueObject. This lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). llvm-svn: 179437
2013-04-13 09:21:23 +08:00
return error;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
bool Scalar::SignExtend(uint32_t sign_bit_pos) {
const uint32_t max_bit_pos = GetByteSize() * 8;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
if (sign_bit_pos < max_bit_pos) {
switch (m_type) {
case Scalar::e_void:
Added the ability to sign extend a Scalar at any bit position for integer types. Added the abilty to set a RegisterValue type via accessor and enum. Added the ability to read arguments for a function for ARM if you are on the first instruction in ABIMacOSX_arm. Fixed an issue where a file descriptor becoming invalid could cause an inifnite loop spin in the libedit thread. llvm-svn: 131610
2011-05-19 08:17:26 +08:00
case Scalar::e_float:
case Scalar::e_double:
case Scalar::e_long_double:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_sint:
case Scalar::e_uint:
case Scalar::e_slong:
case Scalar::e_ulong:
case Scalar::e_slonglong:
case Scalar::e_ulonglong:
case Scalar::e_sint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case Scalar::e_uint128:
case Scalar::e_sint256:
case Scalar::e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case Scalar::e_sint512:
case Scalar::e_uint512:
Added the ability to sign extend a Scalar at any bit position for integer types. Added the abilty to set a RegisterValue type via accessor and enum. Added the ability to read arguments for a function for ARM if you are on the first instruction in ABIMacOSX_arm. Fixed an issue where a file descriptor becoming invalid could cause an inifnite loop spin in the libedit thread. llvm-svn: 131610
2011-05-19 08:17:26 +08:00
if (max_bit_pos == sign_bit_pos)
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
return true;
else if (sign_bit_pos < (max_bit_pos - 1)) {
Changed a use of APInt::getSignBit to APInt::getSignMask. llvm-svn: 300862
2017-04-21 02:07:51 +08:00
llvm::APInt sign_bit = llvm::APInt::getSignMask(sign_bit_pos + 1);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
llvm::APInt bitwize_and = m_integer & sign_bit;
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
if (bitwize_and.getBoolValue()) {
const llvm::APInt mask =
~(sign_bit) + llvm::APInt(m_integer.getBitWidth(), 1);
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer |= mask;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
<rdar://problem/10546739> Fixed SBValue::GetValueAsUnsigned() and SBValue::GetValueAsSigned() calls to work for bitfields. llvm-svn: 147332
2011-12-29 09:26:56 +08:00
return true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
break;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
size_t Scalar::GetAsMemoryData(void *dst, size_t dst_len,
lldb::ByteOrder dst_byte_order,
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
Status &error) const {
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
// Get a data extractor that points to the native scalar data
DataExtractor data;
if (!GetData(data)) {
error.SetErrorString("invalid scalar value");
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return 0;
}
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
const size_t src_len = data.GetByteSize();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
// Prepare a memory buffer that contains some or all of the register value
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
const size_t bytes_copied =
data.CopyByteOrderedData(0, // src offset
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
src_len, // src length
dst, // dst buffer
dst_len, // dst length
dst_byte_order); // dst byte order
if (bytes_copied == 0)
error.SetErrorString("failed to copy data");
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Added new lldb_private::Process memory read/write functions to stop a bunch of duplicated code from appearing all over LLDB: lldb::addr_t Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error); bool Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error); size_t Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error); size_t Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error); in lldb_private::Process the following functions were renamed: From: uint64_t Process::ReadUnsignedInteger (lldb::addr_t load_addr, size_t byte_size, Error &error); To: uint64_t Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr, size_t byte_size, uint64_t fail_value, Error &error); Cleaned up a lot of code that was manually doing what the above functions do to use the functions listed above. Added the ability to get a scalar value as a buffer that can be written down to a process (byte swapping the Scalar value if needed): uint32_t Scalar::GetAsMemoryData (void *dst, uint32_t dst_len, lldb::ByteOrder dst_byte_order, Error &error) const; The "dst_len" can be smaller that the size of the scalar and the least significant bytes will be written. "dst_len" can also be larger and the most significant bytes will be padded with zeroes. Centralized the code that adds or removes address bits for callable and opcode addresses into lldb_private::Target: lldb::addr_t Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; lldb::addr_t Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const; All necessary lldb_private::Address functions now use the target versions so changes should only need to happen in one place if anything needs updating. Fixed up a lot of places that were calling : addr_t Address::GetLoadAddress(Target*); to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress() as needed. There were many places in the breakpoint code where things could go wrong for ARM if these weren't used. llvm-svn: 131878
2011-05-23 06:46:53 +08:00
return bytes_copied;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
}
Revert r244308 since it's introducing test regressions on Linux: - TestLldbGdbServer.py both clang & gcc, i386 and x86_64 - TestConstVariables.py gcc, i386 and x86_64 - 112 failures clang, i386 llvm-svn: 244514
2015-08-11 05:49:50 +08:00
<rdar://problem/10546739> Fixed SBValue::GetValueAsUnsigned() and SBValue::GetValueAsSigned() calls to work for bitfields. llvm-svn: 147332
2011-12-29 09:26:56 +08:00
bool Scalar::ExtractBitfield(uint32_t bit_size, uint32_t bit_offset) {
if (bit_size == 0)
return true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Added the ability to sign extend a Scalar at any bit position for integer types. Added the abilty to set a RegisterValue type via accessor and enum. Added the ability to read arguments for a function for ARM if you are on the first instruction in ABIMacOSX_arm. Fixed an issue where a file descriptor becoming invalid could cause an inifnite loop spin in the libedit thread. llvm-svn: 131610
2011-05-19 08:17:26 +08:00
switch (m_type) {
case Scalar::e_void:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
case Scalar::e_float:
case Scalar::e_double:
case Scalar::e_long_double:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_sint:
case Scalar::e_slong:
case Scalar::e_slonglong:
case Scalar::e_sint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case Scalar::e_sint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case Scalar::e_sint512:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.ashr(bit_offset)
Avoid an assertion failure when a bit field is extracted from a value of the same size. Summary: One of the cases handled by ValueObjectChild::UpdateValue() uses the entire width of the parent's scalar value as the size of the child, and extracts the child by calling Scalar::ExtractBitfield(). This seems valid but APInt::trunc(), APInt::sext() and APInt::zext() assert that the bit field must not have the same size as the parent scalar. Replacing those calls with sextOrTrunc(), zextOrTrunc(), sextOrSelf() and zextOrSelf() fixes the assertion failures. Reviewers: uweigand, labath Subscribers: labath, lldb-commits Differential Revision: http://reviews.llvm.org/D20355 llvm-svn: 270062
2016-05-19 21:51:20 +08:00
.sextOrTrunc(bit_size)
.sextOrSelf(8 * GetByteSize());
<rdar://problem/10546739> Fixed SBValue::GetValueAsUnsigned() and SBValue::GetValueAsSigned() calls to work for bitfields. llvm-svn: 147332
2011-12-29 09:26:56 +08:00
return true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_uint:
case Scalar::e_ulong:
case Scalar::e_ulonglong:
case Scalar::e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case Scalar::e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case Scalar::e_uint512:
Fix usage of APInt.getRawData for big-endian systems 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
2016-04-15 17:55:52 +08:00
m_integer = m_integer.lshr(bit_offset)
Avoid an assertion failure when a bit field is extracted from a value of the same size. Summary: One of the cases handled by ValueObjectChild::UpdateValue() uses the entire width of the parent's scalar value as the size of the child, and extracts the child by calling Scalar::ExtractBitfield(). This seems valid but APInt::trunc(), APInt::sext() and APInt::zext() assert that the bit field must not have the same size as the parent scalar. Replacing those calls with sextOrTrunc(), zextOrTrunc(), sextOrSelf() and zextOrSelf() fixes the assertion failures. Reviewers: uweigand, labath Subscribers: labath, lldb-commits Differential Revision: http://reviews.llvm.org/D20355 llvm-svn: 270062
2016-05-19 21:51:20 +08:00
.zextOrTrunc(bit_size)
.zextOrSelf(8 * GetByteSize());
<rdar://problem/10546739> Fixed SBValue::GetValueAsUnsigned() and SBValue::GetValueAsSigned() calls to work for bitfields. llvm-svn: 147332
2011-12-29 09:26:56 +08:00
return true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
<rdar://problem/10546739> Fixed SBValue::GetValueAsUnsigned() and SBValue::GetValueAsSigned() calls to work for bitfields. llvm-svn: 147332
2011-12-29 09:26:56 +08:00
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Added emulation of shifts to the IR interpreter. <rdar://problem/12978619> llvm-svn: 172013
2013-01-10 06:44:41 +08:00
bool lldb_private::operator==(const Scalar &lhs, const Scalar &rhs) {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// If either entry is void then we can just compare the types
if (lhs.m_type == Scalar::e_void || rhs.m_type == Scalar::e_void)
return lhs.m_type == rhs.m_type;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar temp_value;
const Scalar *a;
const Scalar *b;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
llvm::APFloat::cmpResult result;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (PromoteToMaxType(lhs, rhs, temp_value, a, b)) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_sint:
case Scalar::e_uint:
case Scalar::e_slong:
case Scalar::e_ulong:
case Scalar::e_slonglong:
case Scalar::e_ulonglong:
case Scalar::e_sint128:
case Scalar::e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case Scalar::e_sint256:
case Scalar::e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case Scalar::e_sint512:
case Scalar::e_uint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
return a->m_integer == b->m_integer;
case Scalar::e_float:
case Scalar::e_double:
case Scalar::e_long_double:
result = a->m_float.compare(b->m_float);
if (result == llvm::APFloat::cmpEqual)
<rdar://problem/10546739> Fixed SBValue::GetValueAsUnsigned() and SBValue::GetValueAsSigned() calls to work for bitfields. llvm-svn: 147332
2011-12-29 09:26:56 +08:00
return true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Added emulation of shifts to the IR interpreter. <rdar://problem/12978619> llvm-svn: 172013
2013-01-10 06:44:41 +08:00
bool lldb_private::operator!=(const Scalar &lhs, const Scalar &rhs) {
[Scalar] Implement operator!= using operator==. Summary: Adding some test coverage while I'm around. Reviewers: JDevlieghere, aprantl, zturner, clayborg, jingham Differential Revision: https://reviews.llvm.org/D56017 llvm-svn: 349970
2018-12-22 06:42:00 +08:00
return !(lhs == rhs);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Added emulation of shifts to the IR interpreter. <rdar://problem/12978619> llvm-svn: 172013
2013-01-10 06:44:41 +08:00
bool lldb_private::operator<(const Scalar &lhs, const Scalar &rhs) {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (lhs.m_type == Scalar::e_void || rhs.m_type == Scalar::e_void)
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Scalar temp_value;
const Scalar *a;
const Scalar *b;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
llvm::APFloat::cmpResult result;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (PromoteToMaxType(lhs, rhs, temp_value, a, b)) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case Scalar::e_sint:
case Scalar::e_slong:
case Scalar::e_slonglong:
case Scalar::e_sint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case Scalar::e_sint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case Scalar::e_sint512:
case Scalar::e_uint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
return a->m_integer.slt(b->m_integer);
case Scalar::e_uint:
case Scalar::e_ulong:
case Scalar::e_ulonglong:
case Scalar::e_uint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case Scalar::e_uint256:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
return a->m_integer.ult(b->m_integer);
case Scalar::e_float:
case Scalar::e_double:
case Scalar::e_long_double:
result = a->m_float.compare(b->m_float);
if (result == llvm::APFloat::cmpLessThan)
return true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Added emulation of shifts to the IR interpreter. <rdar://problem/12978619> llvm-svn: 172013
2013-01-10 06:44:41 +08:00
bool lldb_private::operator<=(const Scalar &lhs, const Scalar &rhs) {
[Scalar] Simplify comparison operators and add coverage. llvm-svn: 350428
2019-01-05 03:23:52 +08:00
return !(rhs < lhs);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Added emulation of shifts to the IR interpreter. <rdar://problem/12978619> llvm-svn: 172013
2013-01-10 06:44:41 +08:00
bool lldb_private::operator>(const Scalar &lhs, const Scalar &rhs) {
[Scalar] Simplify comparison operators and add coverage. llvm-svn: 350428
2019-01-05 03:23:52 +08:00
return rhs < lhs;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Added emulation of shifts to the IR interpreter. <rdar://problem/12978619> llvm-svn: 172013
2013-01-10 06:44:41 +08:00
bool lldb_private::operator>=(const Scalar &lhs, const Scalar &rhs) {
[Scalar] Simplify comparison operators and add coverage. llvm-svn: 350428
2019-01-05 03:23:52 +08:00
return !(lhs < rhs);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
<rdar://problem/10546739> Fixed SBValue::GetValueAsUnsigned() and SBValue::GetValueAsSigned() calls to work for bitfields. llvm-svn: 147332
2011-12-29 09:26:56 +08:00
bool Scalar::ClearBit(uint32_t bit) {
Added the ability to sign extend a Scalar at any bit position for integer types. Added the abilty to set a RegisterValue type via accessor and enum. Added the ability to read arguments for a function for ARM if you are on the first instruction in ABIMacOSX_arm. Fixed an issue where a file descriptor becoming invalid could cause an inifnite loop spin in the libedit thread. llvm-svn: 131610
2011-05-19 08:17:26 +08:00
switch (m_type) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_uint128:
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer.clearBit(bit);
return true;
case e_float:
case e_double:
case e_long_double:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
<rdar://problem/10546739> Fixed SBValue::GetValueAsUnsigned() and SBValue::GetValueAsSigned() calls to work for bitfields. llvm-svn: 147332
2011-12-29 09:26:56 +08:00
bool Scalar::SetBit(uint32_t bit) {
Added the ability to sign extend a Scalar at any bit position for integer types. Added the abilty to set a RegisterValue type via accessor and enum. Added the ability to read arguments for a function for ARM if you are on the first instruction in ABIMacOSX_arm. Fixed an issue where a file descriptor becoming invalid could cause an inifnite loop spin in the libedit thread. llvm-svn: 131610
2011-05-19 08:17:26 +08:00
switch (m_type) {
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_void:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
case e_sint:
case e_uint:
case e_slong:
case e_ulong:
case e_slonglong:
case e_ulonglong:
case e_sint128:
Certain hardware architectures have registers of 256 bits in size This patch extends Scalar such that it can support data living in such registers (e.g. float values living in the XMM registers) llvm-svn: 263079
2016-03-10 08:14:29 +08:00
case e_uint128:
case e_sint256:
case e_uint256:
[Scalar] Implement support for 512-bit values. (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
2019-01-31 02:05:36 +08:00
case e_sint512:
case e_uint512:
[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp Reviewers: tberghammer, ovyalov, clayborg, labath Subscribers: lldb-commits, nitesh.jain, jaydeep Differential: http://reviews.llvm.org/D12100 llvm-svn: 245547
2015-08-20 17:12:46 +08:00
m_integer.setBit(bit);
return true;
case e_float:
case e_double:
case e_long_double:
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
DWARFExpression: Fix implementation of DW_OP_pick Summary: The DWARF spec states that the DWARF stack arguments are numbered from the top. Our implementation of DW_OP_pick was counting them from the bottom. This bug probably wasn't noticed because nobody (except my upcoming postfix-to-DWARF converter) uses DW_OP_pick, but I've cross-checked with gdb to confirm that counting from the top is the expected behavior. This patch fixes the implementation to match the spec and gdb behavior and adds a test. Reviewers: jasonmolenda, clayborg Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D61182 llvm-svn: 359436
2019-04-29 18:55:22 +08:00
llvm::raw_ostream &lldb_private::operator<<(llvm::raw_ostream &os, const Scalar &scalar) {
StreamString s;
scalar.GetValue(&s, /*show_type*/ true);
return os << s.GetString();
}