https://github.com/dwblaikie approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/97544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,30 @@
+// XFAIL: *
+
+// RUN: %clangxx_host -gdwarf -o %t %s
+// RUN: %lldb %t \
+// RUN: -o "expr alignof(OverlappingDerived)" \
+// RUN: -o "expr sizeof(OverlappingDerived)" \
+// RUN: -o exit | FileCheck %s
+
+// CHECK: (lldb) expr
dwblaikie wrote:
Oh, this code was touched really recently in
66df6141659375e738d9b9b74bf79b2317576042 (@augusto2112 ) (see notes in previous
comments about how this code should be generalized)
https://github.com/llvm/llvm-project/pull/93809
___
dwblaikie wrote:
Here's the smallest patch that would put explicit alignment on any packed
structure:
```
diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp
b/clang/lib/CodeGen/CGDebugInfo.cpp
index a072475ba770..bbb13ddd593b 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++
dwblaikie wrote:
The other effects of `packed` are encoded (the changes to the member offsets)
but that's not the only effect, and we shouldn't use that effect (which isn't
guaranteed to be observable - as in the case of "packed struct with a single
member/that just happens to not have
dwblaikie wrote:
oh, slight misquote above - `aligned(1)` is a no-op, as that attribute can't
reduce the alignment...
But I think my argument still stands, roughly as - if increases in alignment
are explicitly specified, decreases in alignment should be too.
dwblaikie wrote:
Ah, I think this right solution to /this/ case is that the compiler should be
emitting the alignment for the structure?
Like there's no way for the debugger to know that this structure is
underaligned at the moment:
```
struct __attribute__((packed)) t1 {
int i;
};
```
dwblaikie wrote:
> It looks like the test is flaky:
> https://lab.llvm.org/buildbot/#/builders/59/builds/535
>
> It looks like the order of the types is nondeterministic. I think you should
> be able to use CHECK-DAG along with [this trick to match
>
@@ -1798,6 +1805,13 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext ,
}
if (def_die) {
+if (auto [it, inserted] = dwarf->GetDIEToType().try_emplace(
dwblaikie wrote:
any chance of reducing/avoiding this duplication? Looks like the
dwblaikie wrote:
> > This patch as-is is NFC?
>
> NFC_**I**_, I would say :) I don't think this should change the behavior in
> any way, but it's pretty hard to guarantee that.
Sure enough - I take any claim as a statement of intent/belief, not of
something mathematically proved, etc.
> >
dwblaikie wrote:
This patch as-is is NFC? (no tests) but without this patch, the other
delay-definition-die patch would have had a problem?
Is it possible to add a test in this patch that would exercise the thing that
would become buggy if the delay-definition-die patch were to be
dwblaikie wrote:
> @ZequanWu, @labath, since this PR got reverted due to crash for
> `--gsimple-template-names`, do you guys have a timeline to revise a new
> version without crashing? I ask this because our internal customers have many
> forward declarations that are suffering from the slow
@@ -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
dwblaikie wrote:
> That would mean if someone wrote `struct Empty {}; struct Z { Empty a,b,c;
> }`, we'd lower it to `{ [3 x i8] }` instead of `{%Empty, %Empty, %Empty}`,
> which is a bit ugly. Other than that, sure, I guess we could do that.
Ah, fair enough. Glad to understand and I don't
dwblaikie wrote:
> Oh, in this particular case, the issue isn't the computed datasize, it's that
> FieldDecl::isZeroSize() returns the wrong result. If that's the case, maybe
> we can just change FieldDecl::isZeroSize() to say the field is zero size? So
> essentially, we pretend all empty
dwblaikie wrote:
> Good question, I haven't dug into the modules import mechanism yet, but if
> this is true, then that could give us an opportunity to introduce a "lazy
> method loading" mechanism on the ExternalASTSource that would fit both LLDB
> and modules? Will try to confirm this
dwblaikie wrote:
Yeah, putting this behind a very-explicitly-temporary flag seems reasonable to
me, FWIW.
& yeah, the analogy to modules re: member function expansion seems relevant as
far as I understand things too.
https://github.com/llvm/llvm-project/pull/95100
@@ -2341,9 +2198,7 @@ bool DWARFExpression::Evaluate(
// the stack by the called expression may be used as return values by prior
// agreement between the calling and called expressions.
case DW_OP_call2:
- if (error_ptr)
-
dwblaikie 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
dwblaikie wrote:
One easy question would be: do you/your users use -fdebug-types-section? If so,
that'd probably explain what you were seeing & you could add some test coverage
for that wherever you like (in lldb, presumably, maybe in bolt too). But if
you/they don't, then it's unclear where
dwblaikie wrote:
Could probably adjust the assertions to be `assert (debug || whatever)` rather
than `if (!debug) assert(whatever)`.
My understanding/expectation was that these assertions would be removed
entirely - that whatever generated the AST should just be trusted, whether it's
the
dwblaikie wrote:
But seems like this isn't a DW_IDX_parent issue, then (other than as /maybe/ an
artifact of the producer) - so the description seems misleading. "ignore
invalid named entries that refer to declarations"
A test case/demonstration this is a real problem would be nice, though...
dwblaikie wrote:
As for the original issue this patch is meant to address - I'd still like to
see an example of the problem, as I'm not sure what the issue is. (but,
equally, I'm not a decider in lldb - so don't have to wait on my for approval
if other lldb devs reckon this is the right
dwblaikie wrote:
> "std::ios_base" is forward declared and it contains typedefs whose entries in
> the .debug_names table will point to the DIE at offset 0x0090cdd5. These
> entries cause our type lookups to try and parse a TON of forward declarations
> and waste time and resources.
>
> This
dwblaikie wrote:
Sorry I can't quite figure out who/where to reply to, so perhaps by summarizing
the situation (though it's going to be verbose, and I'm going to add some other
examples/complications) I can get a grip on all this/clarify where we're at.
So, history.
* minimum spec-compliant
dwblaikie wrote:
& FWIW, I think it is valid to include these declarations as entries, though
not as named/index entries, per the spec:
> It is possible that an indexed debugging information entry has a parent that
> is not indexed (for example, if its parent does not have a name attribute).
dwblaikie wrote:
What's an actual test case for this issue? The example given above doesn't look
like it'd produce entries for the declaration of ios_base? Like here's
something that looks equivalent, but is complete, and doesn't have a
DW_IDX_parent on the nested typedef entry in the index:
@@ -24,13 +24,16 @@ class UniqueDWARFASTType {
UniqueDWARFASTType() : m_type_sp(), m_die(), m_declaration() {}
UniqueDWARFASTType(lldb::TypeSP _sp, const DWARFDIE ,
- const Declaration , int32_t byte_size)
+ const Declaration ,
@@ -0,0 +1,40 @@
+# Test definition DIE searching is delayed until complete type is required.
+
+# RUN: split-file %s %t
+# RUN: %clangxx_host %t/main.cpp %t/t1_def.cpp -g -gsimple-template-names -o
%t.out
+# RUN: %lldb -b %t.out -s %t/lldb.cmd | FileCheck %s
+
+# CHECK:
@@ -24,13 +24,16 @@ class UniqueDWARFASTType {
UniqueDWARFASTType() : m_type_sp(), m_die(), m_declaration() {}
UniqueDWARFASTType(lldb::TypeSP _sp, const DWARFDIE ,
- const Declaration , int32_t byte_size)
+ const Declaration ,
@@ -1632,27 +1632,34 @@ bool SymbolFileDWARF::CompleteType(CompilerType
_type) {
return true;
}
- DWARFDIE dwarf_die = GetDIE(die_it->getSecond());
- if (dwarf_die) {
-// Once we start resolving this type, remove it from the forward
-// declaration map in
@@ -0,0 +1,40 @@
+# Test definition DIE searching is delayed until complete type is required.
+
+# RUN: split-file %s %t
+# RUN: %clangxx_host %t/main.cpp %t/t1_def.cpp -g -gsimple-template-names -o
%t.out
+# RUN: %lldb -b %t.out -s %t/lldb.cmd | FileCheck %s
+
+# CHECK:
@@ -16,61 +16,66 @@ using namespace lldb_private::plugin::dwarf;
bool UniqueDWARFASTTypeList::Find(const DWARFDIE ,
const lldb_private::Declaration ,
const int32_t byte_size,
+
Author: David Blaikie
Date: 2024-05-05T17:59:54Z
New Revision: 41574f5a6e2d961f398d3c671c34ac3c8e417464
URL:
https://github.com/llvm/llvm-project/commit/41574f5a6e2d961f398d3c671c34ac3c8e417464
DIFF:
https://github.com/llvm/llvm-project/commit/41574f5a6e2d961f398d3c671c34ac3c8e417464.diff
dwblaikie wrote:
Hmm - but the byte size wouldn't be known from only a declaration, right? so
how'd that key work between a declaration and a definition?
https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
dwblaikie wrote:
does this cause multiple (an open ended amount?) of declarations for a type to
be created if the type declarations from multiple CUs are encountered
separately? Or still only one due to the extra map?
https://github.com/llvm/llvm-project/pull/90663
https://github.com/dwblaikie created
https://github.com/llvm/llvm-project/pull/90008
- DO NOT SUBMIT: lldb DWARF-Clang AST parsing tracing
- Fix scope operator ordering
- DO NOT SUBMIT: Really dodgy demonstration of DWARFTypePrinter reuse in lldb
>From 863343317c47602163d75c13b2687601740e8410
dwblaikie wrote:
looks approximately right to me, but wouldn't' mind a set of eyes more familiar
with lldb to take a look
https://github.com/llvm/llvm-project/pull/88335
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
@@ -273,6 +301,44 @@ void DebugNamesDWARFIndex::GetFullyQualifiedType(
if (!isType(entry.tag()))
continue;
+
+DWARFTypeUnit *foreign_tu = GetForeignTypeUnit(entry);
+if (foreign_tu) {
+ // If this entry represents a foreign type unit, we need to verify
@@ -0,0 +1,91 @@
+// REQUIRES: lld
+
+// This test will make a type that will be compiled differently into two
+// different .dwo files in a type unit with the same type hash, but with
+// differing contents. I have discovered that the hash for the type unit is
+// simply based
@@ -273,6 +301,44 @@ void DebugNamesDWARFIndex::GetFullyQualifiedType(
if (!isType(entry.tag()))
continue;
+
+DWARFTypeUnit *foreign_tu = GetForeignTypeUnit(entry);
+if (foreign_tu) {
+ // If this entry represents a foreign type unit, we need to verify
@@ -273,6 +301,44 @@ void DebugNamesDWARFIndex::GetFullyQualifiedType(
if (!isType(entry.tag()))
continue;
+
+DWARFTypeUnit *foreign_tu = GetForeignTypeUnit(entry);
+if (foreign_tu) {
+ // If this entry represents a foreign type unit, we need to verify
@@ -0,0 +1,91 @@
+// REQUIRES: lld
+
+// This test will make a type that will be compiled differently into two
+// different .dwo files in a type unit with the same type hash, but with
+// differing contents. I have discovered that the hash for the type unit is
+// simply based
@@ -58,6 +58,8 @@ class DWARFDebugInfo {
const DWARFDebugAranges ();
+ const std::shared_ptr GetDwpSymbolFile();
dwblaikie wrote:
Remove const from by-value return. (it messes with move semantics and some
other things) - or was this meant to return by
@@ -1726,44 +1725,59 @@ lldb::ModuleSP
SymbolFileDWARF::GetExternalModule(ConstString name) {
return pos->second;
}
-DWARFDIE
-SymbolFileDWARF::GetDIE(const DIERef _ref) {
- // This method can be called without going through the symbol vendor so we
- // need to lock the
@@ -48,15 +60,31 @@ DebugNamesDWARFIndex::GetUnits(const DebugNames
_names) {
return result;
}
+DWARFTypeUnit *
+DebugNamesDWARFIndex::GetForeignTypeUnit(const DebugNames::Entry ) const
{
+ std::optional type_sig = entry.getForeignTUTypeSignature();
+ if (type_sig)
+
Author: David Blaikie
Date: 2024-04-01T23:07:01Z
New Revision: 9df19ce40281551bd348b262a131085cf98dadf5
URL:
https://github.com/llvm/llvm-project/commit/9df19ce40281551bd348b262a131085cf98dadf5
DIFF:
https://github.com/llvm/llvm-project/commit/9df19ce40281551bd348b262a131085cf98dadf5.diff
dwblaikie wrote:
> For those files in the repository that do need CRLF endings, I've adopted a
> policy of eol=crlf which means that git will store them in history with LF,
> but regardless of user config, they'll be checked out in tree with CRLF.
This ^ seems a bit problematic to me, though
dwblaikie wrote:
(because we don't have a good sense of where feedback should be provided...
crosslinking here from some feedback on the commit:
https://github.com/llvm/llvm-project/commit/d5a277d309e92b1d3e493da6036cffdf815105b1#commitcomment-139991120
)
dwblaikie wrote:
Oh, maybe issues related to layered patches - this is intended to be submitted
after the introduction of the ThreadPoolInterface? But includes those changes
in this review at the moment (I still haven't figured out what we're doing for
dependent changes - and I thought the
dwblaikie wrote:
> I did the first part of the renaming @dwblaikie : looks good?
Hmm - this patch still seems to have both renamings in it, if I'm reading the
PR correctly? I take it from the subject that isn't the intent/the intent is
that his patch only does the
dwblaikie wrote:
> @dwblaikie : how would you split it? I didn't quite get the two renamings you
> have in mind?
One patch `ThreadPool->DefaultThreadPool` (people get a build error about
`ThreadPool` not being the name of anything, find this patch as the root cause,
and rename all their
dwblaikie wrote:
I don't have really firm feelings/justification for this, but I'd have guessed
that doing this as two separate (separated by a few days, maybe a week)
renamings would be better for downstream consumers - they'd get a clear break
without any ambiguity/name reuse.
No strong
dwblaikie wrote:
The dev policy says "Avoid committing formatting- or whitespace-only changes
outside of code you plan to make subsequent changes to." - I think it's
reasonable to consider changing this, but probably under the "clang-format
everything" or a similar discussion (broad
dwblaikie wrote:
> > > If the client strips the debug info first into "a.out.debug" and then
> > > runs llvm-dwp, they will end up with a "a.out.debug.dwp". We have clients
> > > that are doing this already and we want to support them.
> >
> >
> > OK, could we fix llvm-dwp to match the
dwblaikie wrote:
> > > I am fine with telling people what to do and giving them a golden path to
> > > what is easiest for our debuggers. And I will suggest to everyone that
> > > they use `.debug` and `.dwp`, but if we want to only support this, this
> > > leaves the downloading of the
@@ -5401,6 +5409,8 @@ std::string CGDebugInfo::GetName(const Decl *D, bool
Qualified) const {
// feasible some day.
return TA.getAsIntegral().getBitWidth() <= 64 &&
IsReconstitutableType(TA.getIntegralType());
+ case
dwblaikie wrote:
> > > I will aim to land this sometime tomorrow if there are no further
> > > objections
> >
> >
> > Per the documentation (
> > https://llvm.org/docs/CodeReview.html#code-review-workflow ), please don't
> > do this. Once it's sent for review, please wait for approval (ping
dwblaikie wrote:
> I am fine with telling people what to do and giving them a golden path to
> what is easiest for our debuggers. And I will suggest to everyone that they
> use `.debug` and `.dwp`, but if we want to only support this, this leaves the
> downloading of the `.debug` file
dwblaikie wrote:
> I will aim to land this sometime tomorrow if there are no further objections
Per the documentation (
https://llvm.org/docs/CodeReview.html#code-review-workflow ), please don't do
this. Once it's sent for review, please wait for approval (ping as needed, etc)
before
dwblaikie wrote:
> > FWIW, I think we should be opinionated (& consistent with whatever gdb
> > does, if it has some precedent here - if it is less opinionated, then maybe
> > we have to be accepting) when it comes to whether x.debug goes with x.dwp
> > or x.debug.dwp - we shouldn't support
dwblaikie wrote:
> If the DWO ID is just a hash of the file path or something that isn't
> guaranteed to be unique with each new build, then we need the UUID in the
> .dwp file.
Nah, the DWO ID, as per spec, is a semantic hash of the DWARF contents. It
should change, generally, if any part
dwblaikie wrote:
FWIW, I think we should be opinionated (& consistent with whatever gdb does, if
it has some precedent here - if it is less opinionated, then maybe we have to
be accepting) when it comes to whether x.debug goes with x.dwp or x.debug.dwp -
we shouldn't support both unless
dwblaikie wrote:
Be great to see D101950 picked up again, so I'm glad to hear that's being
looked at.
Be nice to get some way to address this regression sooner rather than later...
& yeah, I'd argue that classes derived from DWARF are not complete - nested
types, member function templates,
Author: David Blaikie
Date: 2024-02-02T20:01:51Z
New Revision: f6b387589d648945372528a4ac77c58f310e5165
URL:
https://github.com/llvm/llvm-project/commit/f6b387589d648945372528a4ac77c58f310e5165
DIFF:
https://github.com/llvm/llvm-project/commit/f6b387589d648945372528a4ac77c58f310e5165.diff
dwblaikie wrote:
> > > Even if we want to have the skeleton compile unit be parsed first, we
> > > would need to know this from any accelerator table entry, wether it be
> > > from .debug_names or from our internal manual index.
> >
> >
> > True enough, but I think letting this become a lazy
dwblaikie wrote:
> Even if we want to have the skeleton compile unit be parsed first, we would
> need to know this from any accelerator table entry, wether it be from
> .debug_names or from our internal manual index.
True enough, but I think letting this become a lazy property
dwblaikie wrote:
How'd this work before your recent changes, then - when each repeated query
would get one level further down in the nesting? How'd that work given the
clang limitations you're describing?
In any case, the extra clang requirements here seem like they might be of
uncertain
@@ -218,6 +219,104 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass(
m_fallback.GetCompleteObjCClass(class_name, must_be_implementation,
callback);
}
+namespace {
+using Entry = llvm::DWARFDebugNames::Entry;
+
+/// If `entry` and all of its parents have an `IDX_parent`,
@@ -0,0 +1,210 @@
+//===-- DWARFDIETest.cpp
--=---===//
+//
+// 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:
@@ -218,6 +219,104 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass(
m_fallback.GetCompleteObjCClass(class_name, must_be_implementation,
callback);
}
+namespace {
+using Entry = llvm::DWARFDebugNames::Entry;
+
+/// If `entry` and all of its parents have an `IDX_parent`,
@@ -218,6 +219,104 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass(
m_fallback.GetCompleteObjCClass(class_name, must_be_implementation,
callback);
}
+namespace {
+using Entry = llvm::DWARFDebugNames::Entry;
+
+/// If `entry` and all of its parents have an `IDX_parent`,
@@ -0,0 +1,210 @@
+//===-- DWARFDIETest.cpp
--=---===//
+//
+// 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:
dwblaikie wrote:
> > Thanks for the fix! I did test this patch with both our regression issue,
> > and also allowing us to remove the double-lookup working around #53904 and
> > can confirm it addressed both issues. Thanks again!
>
> Glad it worked! It will also be a huge improvement in the
dwblaikie wrote:
I'm not following all of this, but it appears to be based on the premise that
it's OK that sometimes split units inside a DWP file are parsed before their
skeleton unit? Why is that OK/when/why/where is that happening?
I'd think any case where that happens would be a
@@ -5401,6 +5409,8 @@ std::string CGDebugInfo::GetName(const Decl *D, bool
Qualified) const {
// feasible some day.
return TA.getAsIntegral().getBitWidth() <= 64 &&
IsReconstitutableType(TA.getIntegralType());
+ case
@@ -0,0 +1,23 @@
+# UNSUPPORTED: system-darwin, system-windows
dwblaikie wrote:
That's actually a great question, but I think for now the answer with lldb is
"no, expression evaluation doesn't work without a running process" - but I was
just commenting on an
@@ -0,0 +1,23 @@
+# UNSUPPORTED: system-darwin, system-windows
+
+# In DWARFv5, C++ static data members are represented
+# as DW_TAG_variable. We make sure LLDB's expression
+# evaluator doesn't crash when trying to parse such
+# a DW_TAG_variable DIE, whose parent DIE is only
+#
dwblaikie wrote:
Thanks for the fix! I did test this patch with both our regression issue, and
also allowing us to remove the double-lookup working around #53904 and can
confirm it addressed both issues. Thanks again!
https://github.com/llvm/llvm-project/pull/77029
dwblaikie wrote:
@clayborg any thoughts on this ^ ?
https://github.com/llvm/llvm-project/pull/74786
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
dwblaikie wrote:
FWIW, we're seeing this breaking a pretty printer in google - previously a
lookup was able to find
`absl::cord_internal::RefcountAndFlags::Flags::kNumFlags` (
Author: David Blaikie
Date: 2023-12-14T17:44:18Z
New Revision: 5bc1adff69315dcef670e9fcbe04067b5d5963fb
URL:
https://github.com/llvm/llvm-project/commit/5bc1adff69315dcef670e9fcbe04067b5d5963fb
DIFF:
https://github.com/llvm/llvm-project/commit/5bc1adff69315dcef670e9fcbe04067b5d5963fb.diff
Author: David Blaikie
Date: 2023-12-12T00:07:08Z
New Revision: 2e197602305be18b963928e6ae024a004a95af6d
URL:
https://github.com/llvm/llvm-project/commit/2e197602305be18b963928e6ae024a004a95af6d
DIFF:
https://github.com/llvm/llvm-project/commit/2e197602305be18b963928e6ae024a004a95af6d.diff
dwblaikie wrote:
> To support access to such constants from LLDB we'll most likely have to have
> to make LLDB find the constants by looking at the containing class first.
Tangentially related to:
dwblaikie wrote:
> > I'm arguing it doesn't fit it particularly well. We use it for bit fields -
> > which are pretty special, for instance, but it seems like this thing isn't
> > quite like that - it does have a whole byte size (if you allocated an array
> > of them, for instance, I'm
dwblaikie wrote:
> > I guess one question that might be relevant - does Swift have something
> > like sizeof and what result does it give for these sort of types with bits
> > to spare?
>
> You can't actually use that with these types as these are special compiler
> builtin types which
dwblaikie wrote:
> @dwblaikie I talked with Adrian, his idea is to emit the size in bits
> whenever it does not cleanly fit in a byte. His point (and I agree) is that
> there may be tools that can use this bit size, and if we always round up when
> emitting the DWARF we will lose this
dwblaikie 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
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
https://github.com/dwblaikie approved this pull request.
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
@@ -0,0 +1,87 @@
+// RUN: %clangxx -target arm64-apple-macosx11.0.0 -g %s -emit-llvm -S -o - |
FileCheck --check-prefixes=CHECK %s
+
+enum class Enum : int {
+ VAL = -1
+};
+
+struct Empty {};
+
+constexpr auto func() { return 25; }
+
+struct Foo {
+static constexpr int
@@ -5883,6 +5907,18 @@ void CGDebugInfo::finalize() {
DBuilder.replaceTemporary(std::move(FwdDecl), cast(Repl));
}
+ for (auto const *VD : StaticDataMemberDefinitionsToEmit) {
+assert(VD->isStaticDataMember());
+
+if (auto It = DeclCache.find(VD); It !=
@@ -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:
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? )
dwblaikie wrote:
> > > Should not we remove constant initializer from the type definition if we
> > > have a DW_TAG_variable with a DW_AT_const_value now?
> >
> >
> > Yep, +1 to this. This is where the type normalization benefit would come
> > from - no longer having this const value on the
dwblaikie wrote:
> Summing the size of all *.o files in my local debug Clang build increased by
> 0.7% with this patch
That's a bit significant. Any chance you could get a per-section
breakdown/growth on that? (& exact flags - is this with compressed debug info,
for instance? Or not?) I use
dwblaikie wrote:
> Should not we remove constant initializer from the type definition if we have
> a DW_TAG_variable with a DW_AT_const_value now?
Yep, +1 to this. This is where the type normalization benefit would come from -
no longer having this const value on the member declaration, but
@@ -0,0 +1,87 @@
+// RUN: %clangxx -target arm64-apple-macosx11.0.0 -g %s -emit-llvm -S -o - |
FileCheck --check-prefixes=CHECK %s
+
+enum class Enum : int {
+ VAL = -1
+};
+
+struct Empty {};
+
+constexpr auto func() { return 25; }
+
+struct Foo {
+static constexpr int
@@ -129,8 +129,19 @@ void DebugNamesDWARFIndex::GetGlobalVariables(
DWARFUnit , llvm::function_ref callback) {
uint64_t cu_offset = cu.GetOffset();
bool found_entry_for_cu = false;
- for (const DebugNames::NameIndex : *m_debug_names_up) {
-for
@@ -129,8 +129,19 @@ void DebugNamesDWARFIndex::GetGlobalVariables(
DWARFUnit , llvm::function_ref callback) {
uint64_t cu_offset = cu.GetOffset();
bool found_entry_for_cu = false;
- for (const DebugNames::NameIndex : *m_debug_names_up) {
-for
1 - 100 of 178 matches
Mail list logo
