ayermolo wrote:
What is "nameless index entry"? I don't quite understand from the spec.
https://github.com/llvm/llvm-project/pull/91808
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commi
ayermolo wrote:
Using example above, with a fix by @dwblaikie
I see:
```
Hash: 0xE0CDC6A2
String: 0x0018 "InnerState"
Entry @ 0x10b {
Abbrev: 0x3
Tag: DW_TAG_class_type
DW_IDX_type_unit: 0x01
DW_IDX_die_offset: 0x0030
}
```
Since clan
ayermolo wrote:
> > Using example above, with a fix by @dwblaikie
> > I see:
> > ```
> > Hash: 0xE0CDC6A2
> > String: 0x0018 "InnerState"
> > Entry @ 0x10b {
> > Abbrev: 0x3
> > Tag: DW_TAG_class_type
> > DW_IDX_type_unit: 0x01
> > DW_IDX_die_offse
ayermolo wrote:
> > Since clang no longer emits entry for:
>
> But what does the `debug_info` section look like? In particular, what is the
> _parent_ of the class DIE? If the parent of `InnerState` is not some kind of
> entry for `State` (either a declaration or a definition), IMO Clang is
>
ayermolo wrote:
OK, thanks for detailed explanation.
Will re-read few more time to fully process it. :)
I'll change BOLT behavior to reflect the new clang behavior. If there is a
forward delcaration (skeleton die), the parent chain won't skip it, but instead
won't emit parent for it's children
ayermolo wrote:
I have a follow up question.
For case talked about here earlier:
"namespace A { namespace B { struct State { class InnerState{}; }; } }
A::B::State::InnerState get_state() { return A::B::State::InnerState(); }"
After David fix clang generates:
```
Name 3 {
Hash: 0xE0CDC6A2
ayermolo wrote:
> > I have a follow up question.
>
> It sounds like you've answered it yourself. :)
>
> With this kind of debug info, lldb would think this refers to a global entity
> and return it for queries like `::InnerState`. Without that entry, lldb will
> (correctly) look up the contex
ayermolo wrote:
I have another question.
For the same example.
I see:
```
Name 4 {
Hash: 0x2F94396D
String: 0x0049 "_Z9get_statev"
Entry @ 0x112 {
Abbrev: 0x2
Tag: DW_TAG_subprogram
DW_IDX_die_offset: 0x0023
DW_IDX_parent:
}
...
ayermolo wrote:
Still would be nice to have a small repro to make sure clang, and BOLT, now
does the right thing.
https://github.com/llvm/llvm-project/pull/91808
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
ayermolo 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
ayermolo wrote:
> > @felipepiovezan I have another question. For the same example. I see:
>
> You are right. The fact that they have the same relative offset tells me that
> some part of the code is failing to account for TUs. I just checked the
> printing code in the hope that it was a mistak
@@ -657,6 +657,42 @@ std::optional
DWARFDebugNames::Entry::getLocalTUOffset() const {
return NameIdx->getLocalTUOffset(*Index);
}
+std::optional
+DWARFDebugNames::Entry::getForeignTUTypeSignature() const {
+ std::optional Index = getLocalTUIndex();
+ const uint32_t NumLoc
@@ -657,6 +657,42 @@ std::optional
DWARFDebugNames::Entry::getLocalTUOffset() const {
return NameIdx->getLocalTUOffset(*Index);
}
+std::optional
+DWARFDebugNames::Entry::getForeignTUTypeSignature() const {
+ std::optional Index = getLocalTUIndex();
+ const uint32_t NumLoc
@@ -657,6 +657,42 @@ std::optional
DWARFDebugNames::Entry::getLocalTUOffset() const {
return NameIdx->getLocalTUOffset(*Index);
}
+std::optional
+DWARFDebugNames::Entry::getForeignTUTypeSignature() const {
+ std::optional Index = getLocalTUIndex();
+ const uint32_t NumLoc
ayermolo wrote:
> Most of the patch is very clean, but I'm bothered by the
> `getForeignTUSkeletonCUOffset` function, how it opens up with a mostly
> redundant (the callers checks this already) call to
> `getForeignTUTypeSignature`, and then proceeds with a reimplementation of
> `getCUOffset`
ayermolo wrote:
What happens when Linker tombstones the tu local entry to -1, or will that be
in a separate patch after LLD changes land?
https://github.com/llvm/llvm-project/pull/72952
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https:/
https://github.com/ayermolo approved this pull request.
Thanks for fixing places I missed.
https://github.com/llvm/llvm-project/pull/73736
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-co
https://github.com/ayermolo approved this pull request.
thx
https://github.com/llvm/llvm-project/pull/87164
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -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
ayermolo wrote:
@clayborg
Figured I reply here to your comment:
https://github.com/llvm/llvm-project/pull/88092#issuecomment-2059961175
This was regarding merging .debug_names in linker (although types are not
implemented yet there), but FYI BOLT output is similar.
All the CUs are in one module
ayermolo wrote:
Thanks.
It's failing internally in our automatic multi stage build. Trying to dig into
it as part of my oncall. :)
https://github.com/llvm/llvm-project/pull/89266
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists
ayermolo wrote:
Fixed our internal foobar yesterday. Can close this.
https://github.com/llvm/llvm-project/pull/89266
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
ayermolo wrote:
Hmm, interesting. Thanks for the fix.
https://github.com/llvm/llvm-project/pull/79238
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
ayermolo wrote:
Will this now work with .dwp files not having UUID?
https://github.com/llvm/llvm-project/pull/81067
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
ayermolo wrote:
> > Will this now work with .dwp files not having UUID?
>
> No. If binairies have UUIDs (GNU build IDs), they need to match right now.
> That is larger fix that involves adding a "enum UUIDFlavor" to the UUIDs so
> we can ensure we aren't comparing two different things.
>
> Wh
ayermolo wrote:
Just my 2 cents as a "random dude who works on DWARF". The interoperability of
various gnu extensions and DWARF spec is not well defined. Which leads to
situations like this.
If binary is A then DWP is A.dwp no direct link between binary and dwp file.
If binary has gnulink than
Author: Alexander Yermolovich
Date: 2022-06-22T10:54:25-07:00
New Revision: 130167ed1effa36aa56c83c4293e732e5163d993
URL:
https://github.com/llvm/llvm-project/commit/130167ed1effa36aa56c83c4293e732e5163d993
DIFF:
https://github.com/llvm/llvm-project/commit/130167ed1effa36aa56c83c4293e732e5163d9
Author: Alexander Yermolovich
Date: 2023-01-09T11:29:43-08:00
New Revision: e262b8f48af9fdca8380f2f079e50291956aad71
URL:
https://github.com/llvm/llvm-project/commit/e262b8f48af9fdca8380f2f079e50291956aad71
DIFF:
https://github.com/llvm/llvm-project/commit/e262b8f48af9fdca8380f2f079e50291956aad
Author: Alexander Yermolovich
Date: 2023-01-11T15:07:11-08:00
New Revision: 7fc79340234f3acd354c52bd8bf2cf44f38fc4be
URL:
https://github.com/llvm/llvm-project/commit/7fc79340234f3acd354c52bd8bf2cf44f38fc4be
DIFF:
https://github.com/llvm/llvm-project/commit/7fc79340234f3acd354c52bd8bf2cf44f38fc4
Author: Alexander Yermolovich
Date: 2023-01-12T11:18:29-08:00
New Revision: 4e7da8000e2771907609c3fe149dd4b96cfe0b08
URL:
https://github.com/llvm/llvm-project/commit/4e7da8000e2771907609c3fe149dd4b96cfe0b08
DIFF:
https://github.com/llvm/llvm-project/commit/4e7da8000e2771907609c3fe149dd4b96cfe0b
Author: Alexander Yermolovich
Date: 2023-02-13T13:08:01-08:00
New Revision: f36fe009c0fc1d655bfc6168730bedfa1b36e622
URL:
https://github.com/llvm/llvm-project/commit/f36fe009c0fc1d655bfc6168730bedfa1b36e622
DIFF:
https://github.com/llvm/llvm-project/commit/f36fe009c0fc1d655bfc6168730bedfa1b36e6
Author: Alexander Yermolovich
Date: 2023-02-13T14:08:40-08:00
New Revision: 620b3d9ba3343d7bc5bab2340174a20952fcd00f
URL:
https://github.com/llvm/llvm-project/commit/620b3d9ba3343d7bc5bab2340174a20952fcd00f
DIFF:
https://github.com/llvm/llvm-project/commit/620b3d9ba3343d7bc5bab2340174a20952fcd0
Author: Alexander Yermolovich
Date: 2023-02-16T14:46:13-08:00
New Revision: 2062e90aa531e8445e5dc0e16222c0f246af1bf4
URL:
https://github.com/llvm/llvm-project/commit/2062e90aa531e8445e5dc0e16222c0f246af1bf4
DIFF:
https://github.com/llvm/llvm-project/commit/2062e90aa531e8445e5dc0e16222c0f246af1b
Author: Alexander Yermolovich
Date: 2023-02-16T17:20:27-08:00
New Revision: 8116fc592c5eef88584033ec4f3539f405dee0e0
URL:
https://github.com/llvm/llvm-project/commit/8116fc592c5eef88584033ec4f3539f405dee0e0
DIFF:
https://github.com/llvm/llvm-project/commit/8116fc592c5eef88584033ec4f3539f405dee0
Author: Alexander Yermolovich
Date: 2023-02-22T11:34:00-08:00
New Revision: 34a8e6eee666fe1e67b8b689abe5e4e95bf6b166
URL:
https://github.com/llvm/llvm-project/commit/34a8e6eee666fe1e67b8b689abe5e4e95bf6b166
DIFF:
https://github.com/llvm/llvm-project/commit/34a8e6eee666fe1e67b8b689abe5e4e95bf6b1
Author: Alexander Yermolovich
Date: 2023-03-23T14:03:42-07:00
New Revision: d557384b43d32700ed09b08564a4f7823061d999
URL:
https://github.com/llvm/llvm-project/commit/d557384b43d32700ed09b08564a4f7823061d999
DIFF:
https://github.com/llvm/llvm-project/commit/d557384b43d32700ed09b08564a4f7823061d9
https://github.com/ayermolo updated
https://github.com/llvm/llvm-project/pull/70512
>From 1c6a604df93b833c3bb9c7d34f4f27415592dbe5 Mon Sep 17 00:00:00 2001
From: Alexander Yermolovich
Date: Thu, 5 Oct 2023 12:39:02 -0700
Subject: [PATCH] [LLVM][DWARF] Add support for monolithic types in
.debug
https://github.com/ayermolo closed
https://github.com/llvm/llvm-project/pull/70512
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ayermolo created
https://github.com/llvm/llvm-project/pull/72729
Fixed handling of DWP as input. Before BOLT crashed. Now it will write out
correct CU, and all the TUs. Potential future improvement is to scan all the TUs
used in this CU, and only include those.
>From 80adaca7
40 matches
Mail list logo
