If the implementation of a function requires a string - it should probably
accept string (not a StringRef) as a parameter - to avoid back-and-forth
conversions in cases where the caller already has a string to use.
On Fri, Jul 13, 2018 at 12:43 PM Stella Stamenova via Phabricator via
llvm-commits
On Tue, Aug 28, 2018 at 7:33 AM Greg Clayton via Phabricator <
revi...@reviews.llvm.org> wrote:
> clayborg added a comment.
>
> In https://reviews.llvm.org/D51208#1214743, @dblaikie wrote:
>
> > >> But if LLDB has different performance characteristics, or the default
> should be different for othe
Any chance of using unique_ptr or other RAII/etc ownership to make this API
safer by default?
On Mon, Jan 22, 2018 at 10:58 AM Raphael Isemann via Phabricator via
llvm-commits wrote:
> This revision was not accepted when it landed; it landed in state "Needs
> Review".
> This revision was automat
On Fri, Jul 21, 2017 at 4:05 PM Greg Clayton via Phabricator <
revi...@reviews.llvm.org> wrote:
> clayborg accepted this revision.
> clayborg added a comment.
>
> Looks like there already is a test case that was failing as Jim mentioned.
> Accepting based on that.
>
Ah, I was thinking more a test
On Fri, Jul 21, 2017 at 6:14 PM Jim Ingham wrote:
> Not at present, but you presumably know more about this than I do. Part
> of the point of Greg's extracting the DWARF parser from lldb and making it
> into it's own library in llvm was precisely so that somebody could then
> write a simple wrap
On Sun, Jul 23, 2017 at 10:54 AM Adrian Prantl wrote:
> On Jul 22, 2017, at 2:26 PM, David Blaikie wrote:
>
>
>
> On Fri, Jul 21, 2017 at 6:14 PM Jim Ingham wrote:
>
>> Not at present, but you presumably know more about this than I do. Part
>> of the point of Greg's extracting the DWARF parser
Might be better to only define the variable if HAVE_LIBCOMPRESSION is
defined?
On Wed, Jan 9, 2019 at 8:58 AM Raphael Isemann via Phabricator via
llvm-commits wrote:
> This revision was not accepted when it landed; it landed in state "Needs
> Review".
> This revision was automatically updated to
Author: dblaikie
Date: Thu Jan 5 18:38:12 2017
New Revision: 291200
URL: http://llvm.org/viewvc/llvm-project?rev=291200&view=rev
Log:
Fixes for Clang API changes to use std::shared_ptr
Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
Modified:
lldb/trun
Author: dblaikie
Date: Thu Jan 5 18:38:06 2017
New Revision: 291198
URL: http://llvm.org/viewvc/llvm-project?rev=291198&view=rev
Log:
Make lldb -Werror clean for -Wstring-conversion
Also found/fixed one bug identified by this warning in
RenderScriptx86ABIFixups.cpp where a string literal was bei
Author: dblaikie
Date: Thu Jan 5 18:38:10 2017
New Revision: 291199
URL: http://llvm.org/viewvc/llvm-project?rev=291199&view=rev
Log:
Fix -Wunused-function warning by preprocessor conditionalizing the function the
same way as the caller
Modified:
lldb/trunk/source/Plugins/Process/POSIX/Cras
Author: dblaikie
Date: Thu Jan 5 19:42:56 2017
New Revision: 291204
URL: http://llvm.org/viewvc/llvm-project?rev=291204&view=rev
Log:
Revert part of cleanup to fix a build break
Wasn't sure I could include ErrorHandling.h here, and evidently I wasn't
building this part (must've made the change u
7;
> llvm_unreachable("GetMax32
> unhandled case!"); ^
> /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/tools/debugserver/source/DNBDataRef.cpp:144:5:
> error: use of undeclared identifier 'llvm_unreachable'
> llvm_unreachable("GetMax64 unhandled case!&
Author: dblaikie
Date: Fri Jan 6 11:47:15 2017
New Revision: 291250
URL: http://llvm.org/viewvc/llvm-project?rev=291250&view=rev
Log:
Revert "Fixes for Clang API changes to use std::shared_ptr"
The original Clang change caused a memory leak detected by asan.
Reverting while I investigate.
This
Author: dblaikie
Date: Fri Jan 6 13:49:05 2017
New Revision: 291271
URL: http://llvm.org/viewvc/llvm-project?rev=291271&view=rev
Log:
Reapply "Fixes for Clang API changes to use std::shared_ptr"
Aleksey Shlyapnikov found the memory leak I introduced, recommitted the
Clang change with a fix for t
Thanks for tracking these results, Galina
I think it might be better to send these to the -dev lists, rather than the
-commits lists, but I'm not sure what other people think on that.
On Mon, Nov 30, 2015 at 4:17 PM, Galina Kistanova via cfe-commits <
cfe-comm...@lists.llvm.org> wrote:
> Hello e
On Mon, Nov 30, 2015 at 5:00 PM, Galina Kistanova
wrote:
> Hi David,
>
> Thank you for the useful suggestions, I will work on these.
>
> >I guess the entries with no entry in the failed column have zero failures?
> Yes.
>
> perf-x86_64-penryn-O3-polly-before-vectorizer |
> 31 |
On Fri, Sep 9, 2016 at 7:31 PM Mike Aizatsky wrote:
> aizatsky abandoned this revision.
>
>
> Comment at: include/llvm/Support/JSON.h:207
> @@ +206,3 @@
> +private:
> + typedef std::map Map;
> + typedef Map::iterator Iterator;
>
> zturner wrote:
> > `DenseMap`
dblaikie added a subscriber: dblaikie.
Comment at: test/lang/cpp/incomplete-types/Makefile:8
@@ +7,3 @@
+
+ifneq (,$(findstring clang,$(CC)))
+ CFLAGS_LIMIT += -flimit-debug-info
In case it's interesting, you can get similarly problematic DWARF by using a
dynami
@@ -1798,6 +1805,13 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext &sc,
}
if (def_die) {
+if (auto [it, inserted] = dwarf->GetDIEToType().try_emplace(
dwblaikie wrote:
any chance of reducing/avoiding this duplication? Looks like th
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
> newlines](https://llvm.org/docs/CommandGui
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;
};
```
Which
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.
https://github.com/llvm/llvm-proj
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 padding
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
+++ b/clang/lib/CodeGen/CG
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
___
lldb
@@ -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 alignof(OverlappingDeriv
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
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:
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:
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:
> "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:
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 direct
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:
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 debu
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 t
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 struct/class/
@@ -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)
-error_ptr->SetErrorString("Uni
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
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 (unles
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 fiel
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 fee
@@ -3073,14 +3073,43 @@
SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(const DWARFDIE &die) {
// See comments below about -gsimple-template-names for why we attempt to
// compute missing template parameter names.
-ConstString template_params;
-if (type
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 d
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 recommitted?
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.
> > (n
https://github.com/dwblaikie approved this pull request.
https://github.com/llvm/llvm-project/pull/102793
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
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:
https://discourse.llvm.org/t/rfc-improve-dwarf-5-debug-names-type-lookup-parsing-speed/74151/31?u
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
LOG:
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
LOG:
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` (
https://github.com/abseil/abseil-cpp/blob/8184f16e898fcb13b310b40430e13ba40679cf0e/absl/strings/internal/cord_internal
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:
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
@@ -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
+#
@@ -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 in
Author: David Blaikie
Date: 2023-07-31T18:52:57Z
New Revision: 4e429fd2a72511bc3c0a20e1b12f735863e615df
URL:
https://github.com/llvm/llvm-project/commit/4e429fd2a72511bc3c0a20e1b12f735863e615df
DIFF:
https://github.com/llvm/llvm-project/commit/4e429fd2a72511bc3c0a20e1b12f735863e615df.diff
LOG:
@@ -132,6 +132,84 @@ std::vector GetStrings(const
llvm::json::Object *obj,
return strs;
}
+/// Create a short summary for a container that contains the summary of its
+/// first children, so that the user can get a glimpse of its contents at a
+/// glance.
+static std::opti
dwblaikie wrote:
(aside: isn't the SBAPI meant to be the thing to use if you want to script
stuff, rather than having formatted output/scraping that? - but sounds like the
output has converged on a table rather than JSON anyway? So maybe a moot point)
Re: errors, OSO (what does that stand for
dwblaikie wrote:
> N_SO is the stab moniker for a source file, and N_OSO is the object file
> associated with that source file (N_SO was in Sun's implementation, we made
> up N_OSO). Most nm''s leave off the N_ when they print stabs, so then this
> became just OSO...
> We don't do DWO on Darw
@@ -132,6 +132,84 @@ std::vector GetStrings(const
llvm::json::Object *obj,
return strs;
}
+/// Create a short summary for a container that contains the summary of its
+/// first children, so that the user can get a glimpse of its contents at a
+/// glance.
+static std::opti
@@ -132,6 +132,84 @@ std::vector GetStrings(const
llvm::json::Object *obj,
return strs;
}
+/// Create a short summary for a container that contains the summary of its
+/// first children, so that the user can get a glimpse of its contents at a
+/// glance.
+static std::opti
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 discussion
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 fee
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 Threa
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 ThreadPool->DefaultThreadPool
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 Th
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
)
https://github.com/llvm/llvm-project/
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 (
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
LOG:
@@ -48,15 +60,31 @@ DebugNamesDWARFIndex::GetUnits(const DebugNames
&debug_names) {
return result;
}
+DWARFTypeUnit *
+DebugNamesDWARFIndex::GetForeignTypeUnit(const DebugNames::Entry &entry) const
{
+ std::optional type_sig = entry.getForeignTUTypeSignature();
+ if (typ
@@ -1726,44 +1725,59 @@ lldb::ModuleSP
SymbolFileDWARF::GetExternalModule(ConstString name) {
return pos->second;
}
-DWARFDIE
-SymbolFileDWARF::GetDIE(const DIERef &die_ref) {
- // This method can be called without going through the symbol vendor so we
- // need to lock t
@@ -58,6 +58,8 @@ class DWARFDebugInfo {
const DWARFDebugAranges &GetCompileUnitAranges();
+ 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
@@ -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 of
@@ -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 t
@@ -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 t
@@ -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 of
@@ -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 t
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
https://lists.llvm.org/
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:
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
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
lldb-commits@lists.
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
LOG:
@@ -16,61 +16,66 @@ using namespace lldb_private::plugin::dwarf;
bool UniqueDWARFASTTypeList::Find(const DWARFDIE &die,
const lldb_private::Declaration &decl,
const int32_t byte_size,
+
@@ -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: (ll
@@ -24,13 +24,16 @@ class UniqueDWARFASTType {
UniqueDWARFASTType() : m_type_sp(), m_die(), m_declaration() {}
UniqueDWARFASTType(lldb::TypeSP &type_sp, const DWARFDIE &die,
- const Declaration &decl, int32_t byte_size)
+ const Decla
@@ -1632,27 +1632,34 @@ bool SymbolFileDWARF::CompleteType(CompilerType
&compiler_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 ma
@@ -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: (ll
@@ -24,13 +24,16 @@ class UniqueDWARFASTType {
UniqueDWARFASTType() : m_type_sp(), m_die(), m_declaration() {}
UniqueDWARFASTType(lldb::TypeSP &type_sp, const DWARFDIE &die,
- const Declaration &decl, int32_t byte_size)
+ const Decla
Any chance of test coverage?
On Mon, Dec 13, 2021 at 4:58 PM Jonas Devlieghere via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
>
> Author: Jonas Devlieghere
> Date: 2021-12-13T16:58:39-08:00
> New Revision: 58473d84e0c7796de5dcfd3153e5d5cc8ad034b3
>
> URL:
> https://github.com/llvm/llvm-pr
Author: David Blaikie
Date: 2022-01-23T21:24:25-08:00
New Revision: 8b280df504b97a13d06a929fbc85348903456fdd
URL:
https://github.com/llvm/llvm-project/commit/8b280df504b97a13d06a929fbc85348903456fdd
DIFF:
https://github.com/llvm/llvm-project/commit/8b280df504b97a13d06a929fbc85348903456fdd.diff
Author: David Blaikie
Date: 2022-07-07T19:50:12Z
New Revision: 65cac0ed9266e3551663358de677161ce25a25bf
URL:
https://github.com/llvm/llvm-project/commit/65cac0ed9266e3551663358de677161ce25a25bf
DIFF:
https://github.com/llvm/llvm-project/commit/65cac0ed9266e3551663358de677161ce25a25bf.diff
LOG:
Author: David Blaikie
Date: 2022-07-07T20:13:36Z
New Revision: 856ebe9e8247698095a66f98647ee5d7cb12f337
URL:
https://github.com/llvm/llvm-project/commit/856ebe9e8247698095a66f98647ee5d7cb12f337
DIFF:
https://github.com/llvm/llvm-project/commit/856ebe9e8247698095a66f98647ee5d7cb12f337.diff
LOG:
Author: David Blaikie
Date: 2022-07-07T20:27:05Z
New Revision: 6edbde100132f5dc025bed64059d9fb770abd19e
URL:
https://github.com/llvm/llvm-project/commit/6edbde100132f5dc025bed64059d9fb770abd19e
DIFF:
https://github.com/llvm/llvm-project/commit/6edbde100132f5dc025bed64059d9fb770abd19e.diff
LOG:
Author: David Blaikie
Date: 2022-07-07T20:46:14Z
New Revision: b92c33495aeda7d7fa7f5d3f518c59cc5785fd9f
URL:
https://github.com/llvm/llvm-project/commit/b92c33495aeda7d7fa7f5d3f518c59cc5785fd9f
DIFF:
https://github.com/llvm/llvm-project/commit/b92c33495aeda7d7fa7f5d3f518c59cc5785fd9f.diff
LOG:
Author: David Blaikie
Date: 2022-07-08T00:12:29Z
New Revision: 72d9390778966d4f87ec4b1de63c107b2fd46b9a
URL:
https://github.com/llvm/llvm-project/commit/72d9390778966d4f87ec4b1de63c107b2fd46b9a
DIFF:
https://github.com/llvm/llvm-project/commit/72d9390778966d4f87ec4b1de63c107b2fd46b9a.diff
LOG:
Author: David Blaikie
Date: 2022-08-17T04:10:59Z
New Revision: 9fc65658f5e5a0af5821f4945d78a9f6b8fd368f
URL:
https://github.com/llvm/llvm-project/commit/9fc65658f5e5a0af5821f4945d78a9f6b8fd368f
DIFF:
https://github.com/llvm/llvm-project/commit/9fc65658f5e5a0af5821f4945d78a9f6b8fd368f.diff
LOG:
@@ -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 Template
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 performan
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 ex
@@ -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: Ap
@@ -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`, u
1 - 100 of 192 matches
Mail list logo
