================
@@ -1973,6 +1973,27 @@ class DWARFASTParserClang::DelayedAddObjCClassProperty {
ClangASTMetadata m_metadata;
};
+static clang::APValue MakeAPValue(CompilerType clang_type, uint64_t bit_width,
+ uint64_t value) {
+ bool is_signed = false;
+ const bool is_integral = clang_type.IsIntegerOrEnumerationType(is_signed);
+
+ llvm::APSInt apint(bit_width, !is_signed);
+ apint = value;
+
+ if (is_integral)
+ return clang::APValue(apint);
+
+ uint32_t count;
+ bool is_complex;
+ assert(clang_type.IsFloatingPointType(count, is_complex));
+
+ if (bit_width == 32)
+ return clang::APValue(llvm::APFloat(apint.bitsToFloat()));
+
+ return clang::APValue(llvm::APFloat(apint.bitsToDouble()));
----------------
Michael137 wrote:
Hmmm good question
The only differentiator between the different float types we have in DWARF is
the `DW_AT_name` of the type and the `DW_AT_byte_size`. So we could set the
semantics based on the floating point type, so we probably won't be able to
support all the different available `fltSemantics`. We already create Clang
types from the `DW_AT_name`, so we could, e.g., differentiate between
`_Float16` and `__bf16` semantics by looking at the typename. Then 32-bits and
64-bits we would assume IEEE. And if none of those work then we could return a
`std::nullopt` here? Wdyt?
https://github.com/llvm/llvm-project/pull/127206
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
