[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)
Michael137 wrote:
> This causes Clang to assert:
>
> ```
> llvm/lib/IR/Metadata.cpp:689:
> void llvm::MDNode::resolve(): Assertion `isUniqued() && "Expected this
> to be uniqued"' failed.
> ```
>
> See https://bugs.chromium.org/p/chromium/issues/detail?id=1500262#c1 for a
> reproducer.
>
> I'll revert to green.
Thanks for the repro. Reduced it to:
```
struct Foo;
template using Int = int;
class Bar {
template static const bool Constant = false;
Int> Val;
Bar();
};
Bar::Bar() {}
```
when compiling with `-debug-info-kind=limited`.
The issue was that `EmitGlobalVariable` can cause creation of `DINodes`, which,
if using limited debug-info, will be temporary. But the emission of the global
variables is done *after* we've uniqued the temporaries. So the fix is really
to just do the `EmitGlobalVariable` at the beginning of
`CGDebugInfo::finalize`. Will submit a new PR with that change and a new
test-case for this
https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)
zmodem wrote: This causes Clang to assert: ``` llvm/lib/IR/Metadata.cpp:689: void llvm::MDNode::resolve(): Assertion `isUniqued() && "Expected this to be uniqued"' failed. ``` See https://bugs.chromium.org/p/chromium/issues/detail?id=1500262#c1 for a reproducer. I'll revert to green. https://github.com/llvm/llvm-project/pull/70639 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)
https://github.com/Michael137 closed https://github.com/llvm/llvm-project/pull/70639 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)
avl-llvm wrote: > > 2. always put DW_AT_const_value in DW_TAG_member. > > My understanding is that this is not possible. Dependent initializer > expressions can't be evaluated in all cases - we're only allowed to evaluate > them in the places the language allows us to, otherwise we might produce the > wrong answer. > > For non-dependent initializer expressions I think we could produce the answer > in all cases. > > And if we want type descriptions that are consistent (valuable for use with > Type Units, and with @avl-llvm's DWARFLinker work) and we want to include > static member variables in those descriptions, then we could put the constant > value in the declaration of the member in cases where the initializer is > non-dependent. But we'd still have to put it out in a definition in the > dependent cases (if we want consistency). > > And if we have to put it out in a separate definition DIE anyway - probably > good to do that consistently so there's fewer special cases? > yep. Thanks. So it seems we have to drop DW_AT_const_value from DW_TAG_member if we would like to have consistent type descriptions. > Admittedly there are other reasons type definitions are inconsistent (eg: > implicit special members, nested types, and member function template > specializations (& I guess static member variable template specializations)) > - and we could move static variables out of the authoritative type > definitions the same way we do for those cases. We can see this in type units > (the type unit never has these entities in it, but the skeleton unit that > references the type unit does have these features) - I'd expect something > like that to be what @avl-llvm will want to do with DWARFLinker - though > without type units in input, I'm not sure how easily it'll be to determine > that those are the variant parts that shouldn't go in the canonical type > definition... Speaking for the other cases(It is probably out of the scoop of this patch) Are you saying that f.e. nested types or member function template specializations may look different in different compile units? https://github.com/llvm/llvm-project/pull/70639 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)
avl-llvm wrote: > > Or maybe we can include the DW_AT_const_value in both places? > > The ask to drop the constant off of the declaration comes from the > DWARFParallelLinker work where it was causing non-deterministic output. But > @dwblaikie @avl-llvm will know more about that I do not have a strong opinion which variant is better : 1) remove DW_AT_const_value from DW_TAG_member and put DW_AT_const_value into newly created DW_TAG_variable(which does not have a location). or 2) always put DW_AT_const_value in DW_TAG_member. The problem which parallel DWARFLinker met is that DW_TAG_member from one compilation unit has DW_AT_const_value while the same DW_TAG_member from another compilation unit does not have DW_AT_const_value - https://github.com/llvm/llvm-project/pull/68721#issuecomment-1763409701. If there is a solution when we could always put DW_AT_const_value into the DW_TAG_member (so that DW_TAG_member from different compile units have DW_AT_const_value) - then that would be also a good solution(and we would not need to create additional variable.) Both solutions 1) and 2) are good for parallel DWARFLinker if they result in equal DWARF in different compile units. https://github.com/llvm/llvm-project/pull/70639 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)
Michael137 wrote: > The DWARFASTParserClang, with the current state of things, will automatically > add the const value initializer to the clang AST field. See > `DWARFASTParserClang::ParseSingleMember(...)` around the `// Handle static > members` around > lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2882. The code > extracts the `llvm::Expected const_value_or_err` and then calls > `TypeSystemClang::SetIntegerInitializerForVariable(v, *const_value_or_err);` > to set the constant value of the static member. > > > > I think the expression parser knows how to grab this value if it is in a > static member variable. If this isn't there, it assumes there is a global > variable that backs it and that we will be able to find the location of this > variable in memory. The expression parser will ask for the address of this > value during expression evaluation when it resolves the symbols. Yup, what i was trying to explain is that with the current patch this will break because the expression evaluator neither finds the constant on the declaration (since we removed it) nor via symbol resolution (since they just won't exist for constants). My point was just that if we are to drop the constant from the declaration, we'll have to amend that DWARFASTParserClang logic that you linked so it finds the correct variable definition and take the constant off of that. > It would be nice to add this as a way to indicate this is a constexpr and > that we need to do something special with it. I agree, though i think that can be done in isolation as a follow-up PR. > Is there anyway we can just leave the `DW_AT_const_value` in the > `DW_TAG_member` and then have the `DW_TAG_variable` point to the > `DW_TAG_member` using a `DW_AT_specification` or `DW_AT_abstract_origin`? My > guess this isn't great DWARF where we have a `DW_TAG_variable` have a > specification or abstract origin that points to a different DWARF tag. The variable definition *will* have a specification back to the declaration. > Or maybe we can include the DW_AT_const_value in both places? The ask to drop the constant off of the declaration comes from the DWARFParallelLinker work where it was causing non-deterministic output. But @dwblaikie @avl-llvm will know more about that https://github.com/llvm/llvm-project/pull/70639 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)
clayborg wrote: > > The DWARFASTParserClang.cpp will try to create the class from the DWARF for > > the class definition. You will need to find the DW_TAG_variable when we are > > creating the static field if there is no DW_AT_const_value in the > > DW_TAG_member. But we also need to support the DW_AT_const_value being in > > the DW_TAG_member since older DWARF will be emitted like this. > > That's 100% correct. I was thinking, before [this > block](https://github.com/llvm/llvm-project/blob/8b91de5d6a3f98dcc00bbd286e339e512f7e3682/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp#L2909-L2919) > where we check for the existence of a `const_value_form`, we could try to > look for the definition and take the constant off of that. > > What's interesting is that with this patch, the expression evaluator > successfully finds the `DW_TAG_variable`s which have a location attribute but > not if they have a constant instead of a location. It's probably some logic > that assumes statics always have a location The DWARFASTParserClang, with the current state of things, will automatically add the const value initializer to the clang AST field. See `DWARFASTParserClang::ParseSingleMember(...)` around the `// Handle static members` around lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2882. The code extracts the `llvm::Expected const_value_or_err` and then calls `TypeSystemClang::SetIntegerInitializerForVariable(v, *const_value_or_err);` to set the constant value of the static member. I think the expression parser knows how to grab this value if it is in a static member variable. If this isn't there, it assumes there is a global variable that backs it and that we will be able to find the location of this variable in memory. The expression parser will ask for the address of this value during expression evaluation when it resolves the symbols. > > > Are we going to emit a DW_AT_const_expr now in the DW_TAG_member? If so, > > then we will know that we need to look for the DW_TAG_variable. I don't > > think clang emitted the DW_AT_const_expr attribute before. > > That wasn't part of this patch. But would make sense to add (i've noticed GCC > adds that attribute) It would be nice to add this as a way to indicate this is a constexpr and that we need to do something special with it. Is there anyway we can just leave the `DW_AT_const_value` in the `DW_TAG_member` and then have the `DW_TAG_variable` point to the `DW_TAG_member` using a `DW_AT_specification` or `DW_AT_abstract_origin`? My guess this isn't great DWARF where we have a `DW_TAG_variable` have a specification or abstract origin that points to a different DWARF tag. Or maybe we can include the DW_AT_const_value in both places? https://github.com/llvm/llvm-project/pull/70639 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)
dwblaikie wrote: > That's true, if defined in a header, we'll emit a DW_TAG_variable for the > constant in each compile unit the header is included in. GCC does do the > right thing and only emit the definition DIE in a single CU. We should > probably do the same. Though not sure at which level we want to catch that. Which variable are you discussing here, `val1` or `val2`? For `val1`, we could not emit the constant value and only emit the real definition (there's /some/ risk here - non-ODR uses (or otherwise optimized away uses) of the variable may mean that the object file that defines the variable won't be linked in - so we'd miss the constant value) For `val2` the variable is effectively `inline` and doesn't have a home, so there's no one place that we can emit the `DW_TAG_variable` out-of-line definition... https://github.com/llvm/llvm-project/pull/70639 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)
Michael137 wrote: > One question I have here: where will the DW_TAG_variable get emitted for > these `constexpr`? For actual static member variables we emit a single > DW_TAG_variable in the file that declares the global variable, but for > `constexpr` we won't be able to do this will we? Will we end up emitting a > new copy each time someone include the header file? In that case we might end > up with many global variables being defined in a linked executable that > includes this header file more than once? That's true, if defined in a header, we'll emit a `DW_TAG_variable` for the constant in each compile unit the header is included in. GCC does do the right thing and only emit the definition DIE in a single CU. We should probably do the same. Though not sure at which level. Possibly the DWARF linker? https://github.com/llvm/llvm-project/pull/70639 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/70639
>From 18db082fc5008283f77cc98d9c733a47c63b7096 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Fri, 27 Oct 2023 16:19:47 +0100
Subject: [PATCH 1/7] [clang][DebugInfo] Emit global variable definitions for
static data members with constant initializers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
When an LLDB user asks for the value of a static data member, LLDB starts by
searching the Names accelerator table for the corresponding variable definition
DIE. For static data members with out-of-class definitions that works fine,
because those get represented as global variables with a location and making
them
eligible to be added to the Names table. However, in-class definitions won’t get
indexed because we usually don't emit global variables for them. So in DWARF
we end up with a single `DW_TAG_member` that usually holds the constant
initializer.
But we don't get a corresponding CU-level `DW_TAG_variable` like we do for
out-of-class definitions.
To make it more convenient for debuggers to get to the value of inline static
data members,
this patch makes sure we emit definitions for static variables with constant
initializers
the same way we do for other static variables. This also aligns Clang closer to
GCC, which
produces CU-level definitions for inline statics and also emits these into
`.debug_pubnames`.
The implementation keeps track of newly created static data members. Then in
`CGDebugInfo::finalize`, we emit a global `DW_TAG_variable` with a
`DW_AT_const_value` for
any of those declarations that didn't end up with a definition in the
`DeclCache`.
The newly emitted `DW_TAG_variable` will look as follows:
```
0x007b: DW_TAG_structure_type
DW_AT_calling_convention(DW_CC_pass_by_value)
DW_AT_name ("Foo")
...
0x008d: DW_TAG_member
DW_AT_name("i")
DW_AT_type(0x0062 "const int")
DW_AT_external(true)
DW_AT_declaration (true)
DW_AT_const_value (4)
Newly added
v
0x009a: DW_TAG_variable
DW_AT_specification (0x008d "i")
DW_AT_const_value (4)
DW_AT_linkage_name ("_ZN2t2IiE1iIfEE")
```
---
clang/lib/CodeGen/CGDebugInfo.cpp | 46 +++
clang/lib/CodeGen/CGDebugInfo.h | 6 ++
clang/test/CodeGenCXX/debug-info-class.cpp| 13 ++-
.../debug-info-static-inline-member.cpp | 79 +++
.../TestConstStaticIntegralMember.py | 7 +-
5 files changed, 144 insertions(+), 7 deletions(-)
create mode 100644 clang/test/CodeGenCXX/debug-info-static-inline-member.cpp
diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 0aaf678bf287c6e..7529f114996d2ec 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -1693,6 +1693,7 @@ CGDebugInfo::CreateRecordStaticField(const VarDecl *Var,
llvm::DIType *RecordTy,
llvm::DIDerivedType *GV = DBuilder.createStaticMemberType(
RecordTy, VName, VUnit, LineNumber, VTy, Flags, C, Align);
StaticDataMemberCache[Var->getCanonicalDecl()].reset(GV);
+ StaticDataMemberDefinitionsToEmit.push_back(Var->getCanonicalDecl());
return GV;
}
@@ -5613,6 +5614,39 @@ void CGDebugInfo::EmitGlobalVariable(const ValueDecl
*VD, const APValue ) {
TemplateParameters, Align));
}
+void CGDebugInfo::EmitGlobalVariable(const VarDecl *VD) {
+ assert(VD->hasInit());
+ assert(CGM.getCodeGenOpts().hasReducedDebugInfo());
+ if (VD->hasAttr())
+return;
+
+ auto = DeclCache[VD];
+ if (GV)
+return;
+
+ auto const *InitVal = VD->evaluateValue();
+ if (!InitVal)
+return;
+
+ llvm::DIFile *Unit = nullptr;
+ llvm::DIScope *DContext = nullptr;
+ unsigned LineNo;
+ StringRef DeclName, LinkageName;
+ QualType T;
+ llvm::MDTuple *TemplateParameters = nullptr;
+ collectVarDeclProps(VD, Unit, LineNo, T, DeclName, LinkageName,
+ TemplateParameters, DContext);
+
+ auto Align = getDeclAlignIfRequired(VD, CGM.getContext());
+ llvm::DINodeArray Annotations = CollectBTFDeclTagAnnotations(VD);
+ llvm::DIExpression *InitExpr = createConstantValueExpression(VD, *InitVal);
+
+ GV.reset(DBuilder.createGlobalVariableExpression(
+ TheCU, DeclName, LinkageName, Unit, LineNo, getOrCreateType(T, Unit),
+ true, true, InitExpr, getOrCreateStaticDataMemberDeclarationOrNull(VD),
+ TemplateParameters, Align, Annotations));
+}
+
void CGDebugInfo::EmitExternalVariable(llvm::GlobalVariable *Var,
const VarDecl *D) {
assert(CGM.getCodeGenOpts().hasReducedDebugInfo());
@@ -5883,6 +5917,18 @@ void CGDebugInfo::finalize() {
[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)
Michael137 wrote: > > Few minor issues, but looks good to me. (you metnioned somewhere an lldb > > issue I think with this patch when the value is removed from the static > > member declaration inside the class? If that's a problem - probably hold > > off on committing this until lldb's been fixed so this doesn't regress > > things? And document the dependence clearly in the commit message) > > I saw the patch to lldb to test that we can find global variables that are > `constexpr`. In upstream, we can't use find global variables, but the > expression parser does work for these. We should make sure that both > `FindGlobalVariables(...)` and expression parsing work for all `constexpr` > globals. Yup, the expression evaluator finds them by looking at the `DW_AT_const_value` on the declaration. But since we're moving that constant onto the definition with this patch, that will break that codepath. Looking into how best to address that now https://github.com/llvm/llvm-project/pull/70639 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)
clayborg wrote: > Few minor issues, but looks good to me. (you metnioned somewhere an lldb > issue I think with this patch when the value is removed from the static > member declaration inside the class? If that's a problem - probably hold off > on committing this until lldb's been fixed so this doesn't regress things? > And document the dependence clearly in the commit message) I saw the patch to lldb to test that we can find global variables that are `constexpr`. In upstream, we can't use find global variables, but the expression parser does work for these. We should make sure that both `FindGlobalVariables(...)` and expression parsing work for all `constexpr` globals. https://github.com/llvm/llvm-project/pull/70639 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)
Michael137 wrote: > size report sounds generally OK - but there's a bunch of what look like > unrelated or strange results in there, perhaps they weren't compared at > exactly the same version? (like why did the apple_names size go down? How did > the .text and .debuG_line size change at all? ) Yea I was confused about that too. Might've mixed up commits of the control build. Did measurements again and here's what I got: ``` $ bloaty `find ./patched-build/lib -name *.o ` │ $ bloaty `find ./no-patch-build/lib -name *.o ` FILE SIZEVM SIZE│FILE SIZEVM SIZE -- -- │ -- -- 54.6% 2.02Gi 60.3% 2.02Gi,__debug_str │ 54.5% 2.01Gi 60.3% 2.01Gi,__debug_str 22.0% 834Mi 24.3% 834Mi,__debug_info │ 22.1% 833Mi 24.4% 833Mi,__debug_info 6.2% 236Mi 0.0% 0String Table │ 6.2% 236Mi 0.0% 0String Table 4.5% 170Mi 5.0% 170Mi,__text │ 4.5% 170Mi 5.0% 170Mi,__text 2.6% 97.6Mi 2.8% 97.6Mi,__debug_line │ 2.6% 98.6Mi 2.9% 98.6Mi,__debug_line 2.3% 88.0Mi 2.6% 88.0Mi,__apple_types│ 2.3% 88.0Mi 2.6% 88.0Mi,__apple_types 2.2% 83.1Mi 2.4% 83.1Mi,__apple_names│ 2.2% 81.8Mi 0.0% 0[Unmapped] 2.2% 81.8Mi 0.0% 0[Unmapped]│ 2.1% 77.8Mi 2.3% 77.8Mi,__apple_names 1.7% 65.6Mi 1.9% 65.6Mi,__compact_unwind │ 1.7% 65.6Mi 1.9% 65.6Mi,__compact_unwind 1.0% 39.2Mi 0.0% 0Symbol Table │ 1.0% 39.2Mi 0.0% 0Symbol Table 0.2% 8.05Mi 0.2% 8.05Mi,__const │ 0.2% 8.05Mi 0.2% 8.05Mi,__const 0.2% 7.91Mi 0.2% 7.91Mi,__cstring│ 0.2% 7.92Mi 0.2% 7.92Mi,__cstring 0.1% 5.05Mi 0.1% 5.05Mi,__debug_abbrev │ 0.1% 5.22Mi 0.2% 5.22Mi,__debug_abbrev 0.1% 2.31Mi 0.0% 0[Mach-O Headers] │ 0.1% 2.31Mi 0.0% 0[Mach-O Headers] 0.0% 1.38Mi 0.0% 1.38Mi,__debug_ranges │ 0.0% 1.38Mi 0.0% 1.38Mi,__debug_ranges 0.0% 994Ki 0.0% 994Ki,__apple_namespac │ 0.0% 994Ki 0.0% 994Ki,__apple_namespac 0.0% 0 0.0% 354Ki,__bss│ 0.0% 0 0.0% 354Ki,__bss 0.0% 324Ki 0.0% 324Ki,__data │ 0.0% 324Ki 0.0% 324Ki,__data 0.0% 283Ki 0.0% 283Ki,__StaticInit │ 0.0% 283Ki 0.0% 283Ki,__StaticInit 0.0% 31.3Ki 0.0% 61.4Ki[10 Others] │ 0.0% 31.3Ki 0.0% 61.4Ki[10 Others] 0.0% 58.6Ki 0.0% 58.6Ki,__apple_objc │ 0.0% 58.6Ki 0.0% 58.6Ki,__apple_objc 100.0% 3.70Gi 100.0% 3.35GiTOTAL │ 100.0% 3.69Gi 100.0% 3.34GiTOTAL ``` Section breakdown is still similar https://github.com/llvm/llvm-project/pull/70639 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)
@@ -67,15 +67,15 @@ int C::a = 4; // CHECK-NOT:size: // CHECK-NOT:align: // CHECK-NOT:offset: -// CHECK-SAME: flags: DIFlagStaticMember, -// CHECK-SAME: extraData: i1 true) +// CHECK-SAME: flags: DIFlagStaticMember +// CHECK-NOT:extraData: Michael137 wrote: Merging the two makes sense. I tried that initially but the C++98 FileCheck was tedious to work around. But with the latest iteration of the patch that shouldn't be a problem https://github.com/llvm/llvm-project/pull/70639 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)
dwblaikie wrote: size report sounds generally OK - but there's a bunch of what look like unrelated or strange results in there, perhaps they weren't compared at exactly the same version? (like why did the apple_names size go down? How did the .text and .debuG_line size change at all? ) https://github.com/llvm/llvm-project/pull/70639 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
