@@ -0,0 +1,165 @@
+(* LLDB Debug Expressions, a subset of C++ *)
+(* Insired by https://www.nongnu.org/hcb *)
+
+expression = assignment_expression ;
+
+assignment_expression = conditional_expression
+logical_or_expression assignment_operator
@@ -0,0 +1,165 @@
+(* LLDB Debug Expressions, a subset of C++ *)
+(* Insired by https://www.nongnu.org/hcb *)
+
+expression = assignment_expression ;
+
+assignment_expression = conditional_expression
+logical_or_expression assignment_operator
@@ -0,0 +1,165 @@
+(* LLDB Debug Expressions, a subset of C++ *)
+(* Insired by https://www.nongnu.org/hcb *)
+
+expression = assignment_expression ;
+
+assignment_expression = conditional_expression
+logical_or_expression assignment_operator
https://github.com/Michael137 commented:
Haven't gone through this in detail yet (having an example of how these
structures will be used would be helpful), but something I was curious about is
whether this `DIL` is going to be used in the implementation of a new command,
or if we're going to
@@ -0,0 +1,165 @@
+(* LLDB Debug Expressions, a subset of C++ *)
+(* Insired by https://www.nongnu.org/hcb *)
+
+expression = assignment_expression ;
+
+assignment_expression = conditional_expression
+logical_or_expression assignment_operator
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/95738
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Michael137 wrote:
> It's not that hard to compute "no-data": non-RecordDecls are never no-data,
> RecordDecls are no-data if they don't have a vtable pointer
> (isDynamicClass()), and all fields are no-data. We can save it in the
> CGRecordLayout.
>
> Assuming that's the route we want to go,
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/96290
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Michael Buch
Date: 2024-06-21T20:35:30+01:00
New Revision: 9e6ea387c877a50394aca4b02f18a05e88cf2690
URL:
https://github.com/llvm/llvm-project/commit/9e6ea387c877a50394aca4b02f18a05e88cf2690
DIFF:
https://github.com/llvm/llvm-project/commit/9e6ea387c877a50394aca4b02f18a05e88cf2690.diff
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/96290
>From 67d8bab2d2d42ca3ec5d07efd3be94e614dde2e9 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Thu, 20 Jun 2024 18:29:15 +0100
Subject: [PATCH 1/3] [lldb][ExpressionParser] Add DoPrepareForExecution API
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/96290
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/96290
This patch adds a new `DoPrepareForExecution` API, which can be implemented by
the Clang and Swift language plugins. This also moves `RunStaticInitializers`
into `ExpressionParser::PrepareForExecution`, so
@@ -4744,11 +4744,12 @@
TypeSystemClang::GetBitSize(lldb::opaque_compiler_type_t type,
ExecutionContext exe_ctx(exe_scope);
Process *process = exe_ctx.GetProcessPtr();
if (process) {
-ObjCLanguageRuntime *objc_runtime =
Author: Michael Buch
Date: 2024-06-20T17:53:37+01:00
New Revision: 0ec567c370df86893a22bf59d2716f6e553ca63b
URL:
https://github.com/llvm/llvm-project/commit/0ec567c370df86893a22bf59d2716f6e553ca63b
DIFF:
https://github.com/llvm/llvm-project/commit/0ec567c370df86893a22bf59d2716f6e553ca63b.diff
https://github.com/Michael137 approved this pull request.
https://github.com/llvm/llvm-project/pull/96145
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/96145
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -75,20 +75,18 @@ bool
lldb_private::contextMatches(llvm::ArrayRef context_chain,
static CompilerContextKind ConvertTypeClass(lldb::TypeClass type_class) {
if (type_class == eTypeClassAny)
return CompilerContextKind::AnyType;
- uint16_t result = 0;
- if (type_class
@@ -3073,14 +3073,43 @@
SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(const DWARFDIE ) {
// See comments below about -gsimple-template-names for why we attempt to
// compute missing template parameter names.
-ConstString template_params;
-if
@@ -3073,14 +3073,43 @@
SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(const DWARFDIE ) {
// See comments below about -gsimple-template-names for why we attempt to
// compute missing template parameter names.
-ConstString template_params;
-if
Michael137 wrote:
Ah got it, thanks for clarifying.
> so we could instead just check if the field is empty.
Couldn't find an existing API for this on `FieldDecl`. Here "empty" would be
"field is of a type which is empty"? Which might still cause complications
because a
@@ -4744,11 +4744,12 @@
TypeSystemClang::GetBitSize(lldb::opaque_compiler_type_t type,
ExecutionContext exe_ctx(exe_scope);
Process *process = exe_ctx.GetProcessPtr();
if (process) {
-ObjCLanguageRuntime *objc_runtime =
https://github.com/Michael137 approved this pull request.
LGTM! (minor nit)
https://github.com/llvm/llvm-project/pull/96013
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/96013
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 approved this pull request.
https://github.com/llvm/llvm-project/pull/95905
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -3073,14 +3073,43 @@
SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(const DWARFDIE ) {
// See comments below about -gsimple-template-names for why we attempt to
// compute missing template parameter names.
-ConstString template_params;
-if
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/95963
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/95963
>From 25e64a8a622496cbde447d0d5185f0e7ef06586d Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Tue, 18 Jun 2024 18:04:03 +0100
Subject: [PATCH 1/2] [lldb][ObjC] Don't query objective-c runtime for decls in
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/95963
When LLDB isn't able to find a `clang::Decl` in response to a
`FindExternalVisibleDeclsByName`, it will fall-back to looking into the
Objective-C runtime for that decl. This ends up doing a lot of work which
@@ -3073,14 +3073,43 @@
SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(const DWARFDIE ) {
// See comments below about -gsimple-template-names for why we attempt to
// compute missing template parameter names.
-ConstString template_params;
-if
https://github.com/Michael137 approved this pull request.
https://github.com/llvm/llvm-project/pull/95905
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 deleted
https://github.com/llvm/llvm-project/pull/95905
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -3073,14 +3073,43 @@
SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(const DWARFDIE ) {
// See comments below about -gsimple-template-names for why we attempt to
// compute missing template parameter names.
-ConstString template_params;
-if
@@ -3073,14 +3073,43 @@
SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(const DWARFDIE ) {
// See comments below about -gsimple-template-names for why we attempt to
// compute missing template parameter names.
-ConstString template_params;
-if
@@ -838,16 +838,16 @@ DWARFASTParserClang::ParseTypeModifier(const
SymbolContext ,
return type_sp;
}
-ConstString
+std::string
DWARFASTParserClang::GetDIEClassTemplateParams(const DWARFDIE ) {
if (llvm::StringRef(die.GetName()).contains("<"))
-return ConstString();
https://github.com/Michael137 commented:
makes sense to me, just left some nits
https://github.com/llvm/llvm-project/pull/95905
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -12,7 +12,7 @@
// CHECK: (lldb) target variable
// CHECK-NEXT: (ReferencesBoth<'A'>) both_a = {
// CHECK-NEXT: (Outer<'A'>::Inner *) a = 0x{{[0-9A-Fa-f]*}} {}
-// CHECK-NEXT: (Outer<'A'>::Inner *) b = 0x{{[0-9A-Fa-f]*}} {}
+// CHECK-NEXT: (Outer<'B'>::Inner *) b =
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/95905
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Michael137 wrote:
Yea the problem with checking the size reported by the AST layout vs. the LLVM
type layout is that in DWARF we get following representation:
```
// main.cpp
struct A {
long c, d;
};
struct B {
[[no_unique_address]] Empty x;
};
struct C {
[[no_unique_address]] Empty x;
Michael137 wrote:
> > > The correct answer here is probably to fix the sizes in the RecordLayout
> > > itself; in particular, the DataSize of the members.
> >
> >
> > That would be ideal, but also means we'd have to reflect the various C++
> > attributes that affect layout in DWARF. Avoiding
Michael137 wrote:
> A possibly silly question, but my understanding was that this effort will
> better align us with the interfaces that are used within clang (for compiling
> modules I think). Is that correct?
Regarding Clang interfaces, one of the main benefits of this patch is that we
can
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/95405
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/95405
>From 2e84cf46b9378307d9059aa1ce2a97046b0866b4 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Thu, 13 Jun 2024 14:00:07 +0100
Subject: [PATCH 1/4] [lldb][test] Add test for completing ObjCObjectType
This
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/95402
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/95405
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,10 @@
+// RUN: %clangxx_host %s -g -o %t
+//
+// RUN: %lldb -f %t \
+// RUN: -o "settings set interpreter.stop-command-source-on-error false" \
+// RUN: -o "b main" -o run -o "expression --language objc -- *(id)0x1234" -o
exit 2>&1 | FileCheck %s
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/95405
>From 2e84cf46b9378307d9059aa1ce2a97046b0866b4 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Thu, 13 Jun 2024 14:00:07 +0100
Subject: [PATCH 1/3] [lldb][test] Add test for completing ObjCObjectType
This
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/95402
>From e3ecb1e686e16d90f860126c3ede758196df8f31 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Thu, 13 Jun 2024 13:22:04 +0100
Subject: [PATCH 1/2] [lldb][TypeSystemClang][NFC] Factor completion logic for
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/95402
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -2574,6 +2574,128 @@ TypeSystemClang::GetDeclContextForType(clang::QualType
type) {
return nullptr;
}
+/// Returns the clang::RecordType of the specified \ref qual_type. This
+/// function will try to complete the type if necessary (and allowed
+/// by the specified
@@ -2574,6 +2574,128 @@ TypeSystemClang::GetDeclContextForType(clang::QualType
type) {
return nullptr;
}
+/// Returns the clang::RecordType of the specified \ref qual_type. This
+/// function will try to complete the type if necessary (and allowed
+/// by the specified
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/95405
>From 2e84cf46b9378307d9059aa1ce2a97046b0866b4 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Thu, 13 Jun 2024 14:00:07 +0100
Subject: [PATCH 1/2] [lldb][test] Add test for completing ObjCObjectType
This
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/95405
This is a minimal reproducer for a crash reported internally where we would try
to call `DumpTypeDescription` on an incomplete type. This crash surfaced as
part of an NFC refactor of some of the logic in
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/95402
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/95402
This patch factors out the completion logic for individual clang::Type's into
their own helper functions.
During the process I cleaned up a few assumptions (e.g., unnecessary if-guards
that could be asserts
Michael137 wrote:
> "completing (getting the definition) of the method's arguments and/or return
> types", or something else? My understanding is that we're currently always
> adding the declaration of the methods when completing the class, but that we
> don't eagerly complete the types
https://github.com/Michael137 approved this pull request.
LGTM, the `GetDWARFDeclContext` implementation is definitely easier to grok now
https://github.com/llvm/llvm-project/pull/95227
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
Michael137 wrote:
Only buildkite test failure was `TestConcurrentVFork`, which seemed unrelated.
https://github.com/llvm/llvm-project/pull/91452
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/91452
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/91452
>From d9d0e0de9d57cefc8be78efa5ba9254127c68521 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Wed, 8 May 2024 10:47:54 +0100
Subject: [PATCH 1/2] [lldb][DWARFASTParserClang] Report progress when parsing
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/95175
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/95078
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Michael137 wrote:
> This PR rate limits things. Might be worth trying this out here to see if it
> helps:
>
> #75769
Will try this out, though I haven't found any major performance issues as a
result of the progress events added here. Maybe for different workloads this
could get more
@@ -1758,6 +1759,11 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext ,
}
if (attrs.is_forward_declaration) {
+Progress progress(llvm::formatv(
+"Parsing forward declaration {0}: {1}",
Michael137 wrote:
done
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/91452
>From d9d0e0de9d57cefc8be78efa5ba9254127c68521 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Wed, 8 May 2024 10:47:54 +0100
Subject: [PATCH 1/2] [lldb][DWARFASTParserClang] Report progress when parsing
Michael137 wrote:
Decided to go with something much simpler. Currently just reporting progress in
`ParseStructureLikeDIE`, when we search for the definition DIE. Should reduce
the number of broadcasts to some extent, and once
https://github.com/llvm/llvm-project/pull/92328 lands again, it
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/91452
>From d9d0e0de9d57cefc8be78efa5ba9254127c68521 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Wed, 8 May 2024 10:47:54 +0100
Subject: [PATCH] [lldb][DWARFASTParserClang] Report progress when parsing
types
Michael137 wrote:
@bulbazord raised a good question: do we need this API at all?
>From a brief glance it looks like we're mainly using it for the `operator
>std::string()` conversion operator? Apart from that, there are a couple of
>other callers which probably could just use one of the
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/95175
This patch prevents passing a `nullptr` to the `std::string` constructor in
`GetString`. This prevents UB arising from calling `GetString` on a
default-constructed `ConstString`.
>From
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/95078
>From 75d1bc01ca42e327594cceba753bec483228efbd Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Mon, 10 Jun 2024 17:46:31 +0100
Subject: [PATCH 1/6] [lldb][DWARFASTParser][NFC] Factor out CXX/ObjC method
https://github.com/Michael137 approved this pull request.
Nice, can confirm they're unused on the apple fork too
https://github.com/llvm/llvm-project/pull/95127
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/95078
>From 75d1bc01ca42e327594cceba753bec483228efbd Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Mon, 10 Jun 2024 17:46:31 +0100
Subject: [PATCH 1/6] [lldb][DWARFASTParser][NFC] Factor out CXX/ObjC method
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/95078
>From 75d1bc01ca42e327594cceba753bec483228efbd Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Mon, 10 Jun 2024 17:46:31 +0100
Subject: [PATCH 1/5] [lldb][DWARFASTParser][NFC] Factor out CXX/ObjC method
@@ -975,6 +975,219 @@ ConvertDWARFCallingConventionToClang(const
ParsedDWARFTypeAttributes ) {
return clang::CC_C;
}
+bool DWARFASTParserClang::ParseObjCMethod(
+const ObjCLanguage::MethodName _method, const DWARFDIE ,
+CompilerType clang_type, const
Michael137 wrote:
> * when you say "slower", what exactly does that mean. How much slow down are
> we talking about?
> * the "increased number of DWARF searches", is that due to clang asking for
> definitions of types more eagerly? If yes, do you have some examples of where
> are these extra
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/95078
>From 75d1bc01ca42e327594cceba753bec483228efbd Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Mon, 10 Jun 2024 17:46:31 +0100
Subject: [PATCH 1/4] [lldb][DWARFASTParser][NFC] Factor out CXX/ObjC method
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/95078
>From 75d1bc01ca42e327594cceba753bec483228efbd Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Mon, 10 Jun 2024 17:46:31 +0100
Subject: [PATCH 1/3] [lldb][DWARFASTParser][NFC] Factor out CXX/ObjC method
@@ -975,6 +975,226 @@ ConvertDWARFCallingConventionToClang(const
ParsedDWARFTypeAttributes ) {
return clang::CC_C;
}
+bool DWARFASTParserClang::HandleObjCMethod(
+ObjCLanguage::MethodName const _method, DWARFDIE const ,
+CompilerType clang_type,
@@ -370,6 +371,20 @@ class DWARFASTParserClang : public
lldb_private::plugin::dwarf::DWARFASTParser {
ParsedDWARFTypeAttributes );
lldb::TypeSP ParseSubroutine(const lldb_private::plugin::dwarf::DWARFDIE
,
const
@@ -975,6 +975,226 @@ ConvertDWARFCallingConventionToClang(const
ParsedDWARFTypeAttributes ) {
return clang::CC_C;
}
+bool DWARFASTParserClang::HandleObjCMethod(
+ObjCLanguage::MethodName const _method, DWARFDIE const ,
+CompilerType clang_type,
@@ -370,6 +371,20 @@ class DWARFASTParserClang : public
lldb_private::plugin::dwarf::DWARFASTParser {
ParsedDWARFTypeAttributes );
lldb::TypeSP ParseSubroutine(const lldb_private::plugin::dwarf::DWARFDIE
,
const
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/95078
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -370,6 +371,20 @@ class DWARFASTParserClang : public
lldb_private::plugin::dwarf::DWARFASTParser {
ParsedDWARFTypeAttributes );
lldb::TypeSP ParseSubroutine(const lldb_private::plugin::dwarf::DWARFDIE
,
const
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/95078
This patch moves some of the `is_cxx_method`/`objc_method` logic out of
`DWARFASTParserClang::ParseSubroutine` into their own functions. Mainly the
purpose of this is to (hopefully) make this function more
@@ -491,6 +491,18 @@ static void GetTypeLookupContextImpl(DWARFDIE die,
case DW_TAG_base_type:
push_ctx(CompilerContextKind::Builtin, name);
break;
+// If any of the tags below appear in the parent chain, stop the decl
+// context and return. Prior to
@@ -0,0 +1,69 @@
+"""
Michael137 wrote:
There's also a unit-test for `GetTypeLookupContext` in
`lldb/unittests/SymbolFile/DWARF/DWARFDIETest.cpp`. Would be nice to add a
test-case there too (if the yaml isn't too much of a hassle)
https://github.com/Michael137 approved this pull request.
LGTM, thanks for the tests
https://github.com/llvm/llvm-project/pull/94744
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/94400
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Michael137 wrote:
We might want to consider not omitting these constants into the index with
dsymutil (since it's not spec conforming). And instead fix the expression
evaluator to find the constants from context (but iirc that was a non-trivial
undertaking).
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/94400
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/94400
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/94400
…ss/union types
This is a follow-up of
https://github.com/llvm/llvm-project/pull/92328#issuecomment-2145849441
Clang attaches `DW_AT_declaration` to static inline data members and `dsymutil`
indexes these
Michael137 wrote:
> (Zequan is OOO for three weeks, I can take over this (tomorrow) if needed.)
Ah no worries! I can put up the patch later today then to unblock the CI
https://github.com/llvm/llvm-project/pull/92328
___
lldb-commits mailing list
Michael137 wrote:
> > Should we allow such entries in the index? And does this warrant rephrasing
> > in the DWARF spec?
>
> It's fine to have those as _nameless_ entries (which we don't emit today),
> but the entries that are reaching "process entry" have a name by definition.
> That if
Michael137 wrote:
> > You can repro this by running ./bin/lldb-dotest -p
> > TestConstStaticIntegralMember.py --dwarf-version 5
> > Could you take a look @ZequanWu ?
>
> It should be fixed by the following diff. We just need to skip the
> declaration DIEs that are struct/class/union. This
Michael137 wrote:
What platform was this failing on for you? We have a matrix bot for macOS that
runs these tests on older Clang versions.
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake-matrix/
I probably wrote these checks when clang was on 16.0 to fix the matrix bot
Michael137 wrote:
Sorry for the late ping, but the LLDB matrix bot failure has gone unnoticed for
a bit. This patch caused following test to fail for DWARFv5:
```
FAIL: test_inline_static_members_dsym (TestConstStaticIntegralMember.TestCase)
Author: Michael Buch
Date: 2024-06-03T17:04:16+01:00
New Revision: aad7874000faed77836e2bbd5c72af8776636f89
URL:
https://github.com/llvm/llvm-project/commit/aad7874000faed77836e2bbd5c72af8776636f89
DIFF:
https://github.com/llvm/llvm-project/commit/aad7874000faed77836e2bbd5c72af8776636f89.diff
Michael137 wrote:
Note I'm also seeing some flakiness on the public macOS buildbots:
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake-matrix/322/execution/node/69/log/
https://github.com/llvm/llvm-project/pull/74894
___
lldb-commits
https://github.com/Michael137 approved this pull request.
https://github.com/llvm/llvm-project/pull/94196
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Michael137 wrote:
> The correct answer here is probably to fix the sizes in the RecordLayout
> itself; in particular, the DataSize of the members.
That would be ideal, but also means we'd have to reflect the various C++
attributes that affect layout in DWARF. Avoiding adding such
101 - 200 of 864 matches
Mail list logo
