dwblaikie wrote:
looking good from what I've tested - thanks again!
https://github.com/llvm/llvm-project/pull/72235
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Michael137 wrote:
@dwblaikie merged the fix, let me know if you're still seeing problems
https://github.com/llvm/llvm-project/pull/72235
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
Michael137 wrote:
Proposed fix: https://github.com/llvm/llvm-project/pull/77155
https://github.com/llvm/llvm-project/pull/72235
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
Thanks!
https://github.com/llvm/llvm-project/pull/72235
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Michael137 wrote:
> Yes, in the totally reduced reproducer - another debugger might be able to do
> this name lookup with only a declaration, but I understand that at least
> Clang's AST expression evaluator wouldn't be able to handle this case.
> (though perhaps the lldb-eval work will
dwblaikie wrote:
Yes, in the totally reduced reproducer - another debugger might be able to do
this name lookup with only a declaration, but I understand that at least
Clang's AST expression evaluator wouldn't be able to handle this case. (though
perhaps the lldb-eval work will provide some
Michael137 wrote:
Ah looks like in `GetClangDeclForDIE`, when trying to parse the
`DW_AT_specification` that the CU-level `DW_TAG_variable` points to, we now try
to `CreateVariableDeclaration`, because the static member is a
`DW_TAG_variable` too. Whereas previously we would just fall-through
dwblaikie wrote:
In our practical example this clearly reproduces in cases where the definition
is available in another .dwo within the same executable. So I'm guessing
something needs to go looking for a definition (& then if it can't find one,
fail gracefully) here. There's probably some
Michael137 wrote:
> Yeah, that seems to do it:
>
> ```
>
> struct t1 {
>
> t1();
>
> static int i;
>
> };
>
> int t1::i = 43;
>
> int main() {
>
> }
>
> ```
>
> ```
>
> $ clang++-tot -gsplit-dwarf -g test.cpp
>
> $ lldb ./a.out -o "b main" -o "run" -o "p t1::i" -batch
>
> This
dwblaikie wrote:
Yeah, that seems to do it:
```
struct t1 {
t1();
static int i;
};
int t1::i = 43;
int main() {
}
```
```
$ clang++-tot -gsplit-dwarf -g test.cpp
$ lldb ./a.out -o "b main" -o "run" -o "p t1::i" -batch
This is google-lldb.
Help: http://go/lldb. File a bug: http://go/lldb-bug.
dwblaikie wrote:
Perhaps not surprisingly from the backtrace, the DIE that's tripping things up
is the DW_TAG_variable here:
```
0x3819: DW_TAG_class_type
DW_AT_name ("ScopedLockService")
DW_AT_declaration (true)
0x381b: DW_TAG_variable
dwblaikie wrote:
> > Should've mentioned this earlier, but we've been seeing crashes in lldb due
> > to this change (though possibly related to our use of GALA python/gdb
> > interop https://github.com/sivachandra/gala - we haven't isolated the
> > failures from that yet (though we've been
Michael137 wrote:
> Should've mentioned this earlier, but we've been seeing crashes in lldb due
> to this change (though possibly related to our use of GALA python/gdb interop
> https://github.com/sivachandra/gala - we haven't isolated the failures from
> that yet (though we've been using it
dwblaikie wrote:
Should've mentioned this earlier, but we've been seeing crashes in lldb due to
this change (though possibly related to our use of GALA python/gdb interop
https://github.com/sivachandra/gala - we haven't isolated the failures from
that yet (though we've been using it for
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/72235
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/72235
>From a933f170dcbdbaf76f93a15cdb1c1148d78a82e8 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Mon, 13 Nov 2023 09:48:39 +
Subject: [PATCH] [clang][DebugInfo] DWARFv5: static data members declarations
https://github.com/dwblaikie approved this pull request.
SGTM
https://github.com/llvm/llvm-project/pull/72235
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/72235
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/72235
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/72235
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-clang-codegen
Author: Michael Buch (Michael137)
Changes
This patch implements the DWARFv5 issue
161118.1: "DW_TAG for C++ static data members".
This will simplify LLDB's handling of static data
members greatly in the long term since we no longer need
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/72235
This patch implements the DWARFv5 issue
161118.1: "DW_TAG for C++ static data members".
This will simplify LLDB's handling of static data
members greatly in the long term since we no longer need to
22 matches
Mail list logo
