[Lldb-commits] [PATCH] D54843: [Expr] Check the language before ignoring Objective C keywords
aleksandr.urakov created this revision.
aleksandr.urakov added reviewers: jingham, zturner.
aleksandr.urakov added a project: LLDB.
Herald added a subscriber: lldb-commits.
This patch adds the check of the language before ignoring names like `id` or
`Class`, which are reserved in Objective C, but allowed in C++. It is needed to
make it possible to evaluate expressions in a C++ program containing names like
`id` or `Class`.
There was a discussion of this at the end of October 2018 in `lldb-dev`.
Repository:
rLLDB LLDB
https://reviews.llvm.org/D54843
Files:
packages/Python/lldbsuite/test/expression_command/options/TestExprOptions.py
packages/Python/lldbsuite/test/expression_command/options/main.cpp
source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -398,10 +398,6 @@
LLVM_FALLTHROUGH;
case lldb::eLanguageTypeC_plus_plus_03:
m_compiler->getLangOpts().CPlusPlus = true;
-// FIXME: the following language option is a temporary workaround,
-// to "ask for C++, get ObjC++". Apple hopes to remove this requirement on
-// non-Apple platforms, but for now it is needed.
-m_compiler->getLangOpts().ObjC = true;
break;
case lldb::eLanguageTypeObjC_plus_plus:
case lldb::eLanguageTypeUnknown:
Index: source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
@@ -771,8 +771,9 @@
static const ConstString id_name("id");
static const ConstString Class_name("Class");
- if (name == id_name || name == Class_name)
-return true;
+ if (m_ast_context->getLangOpts().ObjC)
+if (name == id_name || name == Class_name)
+ return true;
StringRef name_string_ref = name.GetStringRef();
Index: packages/Python/lldbsuite/test/expression_command/options/main.cpp
===
--- packages/Python/lldbsuite/test/expression_command/options/main.cpp
+++ packages/Python/lldbsuite/test/expression_command/options/main.cpp
@@ -1,5 +1,6 @@
extern "C" int foo(void);
static int static_value = 0;
+static int id = 1234;
int
bar()
Index:
packages/Python/lldbsuite/test/expression_command/options/TestExprOptions.py
===
--- packages/Python/lldbsuite/test/expression_command/options/TestExprOptions.py
+++ packages/Python/lldbsuite/test/expression_command/options/TestExprOptions.py
@@ -63,3 +63,16 @@
val = frame.EvaluateExpression('foo != nullptr', options)
self.assertTrue(val.IsValid())
self.assertFalse(val.GetError().Success())
+
+# Make sure we can retrieve `id` variable if language is set to C++11:
+options.SetLanguage(lldb.eLanguageTypeC_plus_plus_11)
+val = frame.EvaluateExpression('id == 1234', options)
+self.assertTrue(val.IsValid())
+self.assertTrue(val.GetError().Success())
+self.DebugSBValue(val)
+
+# Make sure we can't retrieve `id` variable if language is set to ObjC:
+options.SetLanguage(lldb.eLanguageTypeObjC)
+val = frame.EvaluateExpression('id == 1234', options)
+self.assertTrue(val.IsValid())
+self.assertFalse(val.GetError().Success())
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -398,10 +398,6 @@
LLVM_FALLTHROUGH;
case lldb::eLanguageTypeC_plus_plus_03:
m_compiler->getLangOpts().CPlusPlus = true;
-// FIXME: the following language option is a temporary workaround,
-// to "ask for C++, get ObjC++". Apple hopes to remove this requirement on
-// non-Apple platforms, but for now it is needed.
-m_compiler->getLangOpts().ObjC = true;
break;
case lldb::eLanguageTypeObjC_plus_plus:
case lldb::eLanguageTypeUnknown:
Index: source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
@@ -771,8 +771,9 @@
static const ConstString id_name("id");
static const ConstString Class_name("Class");
- if (name == id_name || name == Class_name)
-return true;
+ if (m_ast_context->getLangOpts().ObjC)
+if (name == id_name || name == Class_name)
+ retur
[Lldb-commits] [PATCH] D54843: [Expr] Check the language before ignoring Objective C keywords
aleksandr.urakov added inline comments. Comment at: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp:401-404 -// FIXME: the following language option is a temporary workaround, -// to "ask for C++, get ObjC++". Apple hopes to remove this requirement on -// non-Apple platforms, but for now it is needed. -m_compiler->getLangOpts().ObjC = true; Is it still necessary? We can do here something like `#ifdef __APPLE__`, but then the test will fail on Apple platforms. Can we somehow specify a platform requirement in the test? Repository: rLLDB LLDB https://reviews.llvm.org/D54843 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54844: [LLDB] - Improve the support of .debug_str_offsets/.debug_str_offsets.dwo
grimar created this revision.
grimar added reviewers: LLDB, clayborg.
Herald added subscribers: JDevlieghere, aprantl.
A skeleton compilation unit may contain the DW_AT_str_offsets_base attribute
that points to the first string offset of the CU contribution to the
.debug_str_offsets. At the same time, when we use split dwarf,
the corresponding split debug unit also
may use DW_FORM_strx* forms pointing to its own .debug_str_offsets.dwo.
In that case, DWO does not contain DW_AT_str_offsets_base, but LLDB
still need to know and skip the .debug_str_offsets.dwo section header to
access the offsets.
The patch implements the support of DW_AT_str_offsets_base.
A test case showing the use case is provided.
This patch uses a bit of code from https://reviews.llvm.org/D54751, so I assume
the
latter should be landed first.
https://reviews.llvm.org/D54844
Files:
lit/Breakpoint/Inputs/split-dwarf5-debug-stroffsets-file1.dwo.yaml
lit/Breakpoint/Inputs/split-dwarf5-debug-stroffsets-file2.dwo.yaml
lit/Breakpoint/Inputs/split-dwarf5-debug-stroffsets-main.yaml
lit/Breakpoint/split-dwarf5-debug-stroffsets.test
source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
source/Plugins/SymbolFile/DWARF/DWARFUnit.h
Index: source/Plugins/SymbolFile/DWARF/DWARFUnit.h
===
--- source/Plugins/SymbolFile/DWARF/DWARFUnit.h
+++ source/Plugins/SymbolFile/DWARF/DWARFUnit.h
@@ -111,9 +111,11 @@
dw_addr_t GetBaseAddress() const { return m_base_addr; }
dw_addr_t GetAddrBase() const { return m_addr_base; }
dw_addr_t GetRangesBase() const { return m_ranges_base; }
+ dw_addr_t GetStrOffsetsBase() const { return m_str_offsets_base; }
void SetAddrBase(dw_addr_t addr_base);
void SetRangesBase(dw_addr_t ranges_base);
void SetBaseObjOffset(dw_offset_t base_obj_offset);
+ void SetStrOffsetsBase(dw_offset_t str_offsets_base);
void BuildAddressRangeTable(SymbolFileDWARF *dwarf,
DWARFDebugAranges *debug_aranges);
@@ -217,7 +219,7 @@
// If this is a dwo compile unit this is the offset of the base compile unit
// in the main object file
dw_offset_t m_base_obj_offset = DW_INVALID_OFFSET;
-
+ dw_offset_t m_str_offsets_base = 0; // Value of DW_AT_str_offsets_base.
// Offset of the initial length field.
dw_offset_t m_offset;
Index: source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
===
--- source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -305,18 +305,50 @@
}
}
+// This is used when a split dwarf is enabled.
+// A skeleton compilation unit may contain the DW_AT_str_offsets_base attribute
+// that points to the first string offset of the CU contribution to the
+// .debug_str_offsets. At the same time, the corresponding split debug unit also
+// may use DW_FORM_strx* forms pointing to its own .debug_str_offsets.dwo and
+// for that case, we should find the offset (skip the section header).
+static void SetDwoStrOffsetsBase(DWARFUnit *dwo_cu) {
+ lldb::offset_t baseOffset = 0;
+
+ const DWARFDataExtractor &strOffsets =
+ dwo_cu->GetSymbolFileDWARF()->get_debug_str_offsets_data();
+ uint64_t length = strOffsets.GetU32(&baseOffset);
+ if (length == 0x)
+length = strOffsets.GetU64(&baseOffset);
+
+ // Check version.
+ if (strOffsets.GetU16(&baseOffset) < 5)
+return;
+
+ // Skip padding.
+ baseOffset += 2;
+
+ dwo_cu->SetStrOffsetsBase(baseOffset);
+}
+
// m_die_array_mutex must be already held as read/write.
void DWARFUnit::AddUnitDIE(const DWARFDebugInfoEntry &cu_die) {
- SetAddrBase(
- cu_die.GetAttributeValueAsUnsigned(m_dwarf, this, DW_AT_addr_base, 0));
- SetRangesBase(cu_die.GetAttributeValueAsUnsigned(m_dwarf, this,
- DW_AT_rnglists_base, 0));
+ dw_addr_t addr_base =
+ cu_die.GetAttributeValueAsUnsigned(m_dwarf, this, DW_AT_addr_base, 0);
+ SetAddrBase(addr_base);
+
+ dw_addr_t ranges_base =
+ cu_die.GetAttributeValueAsUnsigned(m_dwarf, this, DW_AT_rnglists_base, 0);
+ SetRangesBase(ranges_base);
+
+ dw_addr_t str_offsets_base = cu_die.GetAttributeValueAsUnsigned(
+ m_dwarf, this, DW_AT_str_offsets_base, 0);
+ SetStrOffsetsBase(str_offsets_base);
uint64_t base_addr = cu_die.GetAttributeValueAsAddress(
m_dwarf, this, DW_AT_low_pc, LLDB_INVALID_ADDRESS);
if (base_addr == LLDB_INVALID_ADDRESS)
-base_addr = cu_die.GetAttributeValueAsAddress(
-m_dwarf, this, DW_AT_entry_pc, 0);
+base_addr =
+cu_die.GetAttributeValueAsAddress(m_dwarf, this, DW_AT_entry_pc, 0);
SetBaseAddress(base_addr);
std::unique_ptr dwo_symbol_file =
@@ -342,15 +374,19 @@
m_dwo_symbol_file = std::move(dwo_symbol_file);
- dw_addr_t addr_base =
- cu_die.GetAttributeValueAsUnsigned(m_dwarf, this, DW_AT_GNU_addr_base, 0);
+ if
