tromey wrote:
`DW_AT_specification` has a fairly specific meaning in DWARF. I don't really
understand why you want to link from the class type to the vtable (the reverse
seems more useful to me), but I would suggest a new attribute, considering it
is a new capability. The link from the class
tromey wrote:
> > The link from the class to the specific vtable even seems mildly incorrect,
> > in that during object construction the vtable will go through several
> > different values, not just one.
>
> Not sure I follow this - the object is only of the type, in some sense, when
> it is
tromey wrote:
> But, yeah, I wouldn't mind hearing more about lldb's
> needs/preferences/hopes/dreams for this feature so we might get a design
> that's more portable at least between SCE and LLDB. (bonus points if anyone's
> got GDB's needs in mind - perhaps @tromey might be able to lend us s
tromey wrote:
> Removing the vtable global variable and moving the "location info" into the
> static within the class, will work for the SCE debugger.
I was thinking about this last night and wondering if the vtable will appear as
a class member even if the class is local to a function?
If so
tromey wrote:
> Given the _vtable$ artificial member: use the DW_AT_containing_type to find
> the vtable global variable.
It seems to me that this attribute should refer to a type and not a variable.
https://github.com/llvm/llvm-project/pull/130255
_
tromey wrote:
> As a note - when you say "at the CU scope" do you mean a direct child of the
> CU, or anything outside a function or class definition? (ie: could be inside
> a namespace) - Clang puts definitions, I think, in the namespace nearest the
> declaration for the definition - compare
tromey wrote:
> Uploaded a patch that eliminates the global variable and it moves the vtable
> information into the static member; in that way, a consumer always will have
> access to the vtable information, just by having the object instance or the
> object definition.
IIUC this means that t
tromey wrote:
> My intent (haven't checked the patch) is that it'd be modeled as a static
> member variable - so there'd be a declaration in the class, but a definition
> DIE outside the class that'd be indexed by gdb OK, I'd have thought? (it'd go
> in .debug_names, and gdb_index, I think - f
tromey wrote:
Apologies if I missed it, but one thing I didn't see in the patch is a test for
the case where a class is defined inside a function.
Given the discussion
[here](https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subpro
tromey wrote:
I rebased this and fixed up the mlir problem. I also changed how the overload
resolution was done, so that a later patch that treats `nullptr` specially can
be done without affecting existing call sites.
https://github.com/llvm/llvm-project/pull/141106
__
tromey wrote:
>From what I can tell, those failures don't have anything to do with this patch.
https://github.com/llvm/llvm-project/pull/141106
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-
tromey wrote:
I've rebased this and addressed the review comments. I am leaving the one
sub-thread open since I wasn't sure if I should send a separate PR (I don't
have push rights so I can't land something separately on my own) -- just let me
know if you'd like that, it's no trouble. Thanks
@@ -834,8 +834,8 @@ llvm::DIType *CGDebugInfo::CreateType(const BuiltinType
*BT) {
auto *ISATy = DBuilder.createPointerType(ClassTy, Size);
ObjTy = DBuilder.createStructType(TheCU, "objc_object", TheCU->getFile(),
0,
- 0, 0, llvm:
@@ -1525,15 +1525,24 @@ Error
MetadataLoader::MetadataLoaderImpl::parseOneMetadata(
if (Record.size() < 6 || Record.size() > 8)
return error("Invalid record");
-IsDistinct = Record[0];
+IsDistinct = Record[0] & 1;
+bool SizeIsMetadata = Record[0] & 2;
tromey wrote:
Rebased and adapted to the `LLVM_ABI` change.
https://github.com/llvm/llvm-project/pull/141106
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -966,20 +992,42 @@ class DIFixedPointType : public DIBasicType {
uint64_t SizeInBits, uint32_t AlignInBits, unsigned Encoding,
DIFlags Flags, unsigned Kind, int Factor, APInt Numerator,
APInt Denominator, StorageType Storage, bool ShouldCreate =
tromey wrote:
Updated to fix a tiny error I'd introduced.
https://github.com/llvm/llvm-project/pull/141106
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tromey wrote:
Ping.
https://github.com/llvm/llvm-project/pull/141106
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tromey wrote:
> I am seeing an assertion failure when building the Linux kernel for aarch64
> with LTO enabled. cvise spits out:
Is this still happening for you? If so I will look at it this week. Sorry
about this.
https://github.com/llvm/llvm-project/pull/141106
___
tromey wrote:
FWIW I read through the DWARF/debuginfo bits and it looked reasonable to me. I
found a couple small nits. I didn't read the other parts though.
https://github.com/llvm/llvm-project/pull/141937
___
cfe-commits mailing list
cfe-commits@l
tromey wrote:
I have a fix for the crash that I'll send momentarily.
https://github.com/llvm/llvm-project/pull/141106
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tromey wrote:
> > I have a fix for the crash that I'll send momentarily.
>
> Do you have a link?
Patch is up now: https://github.com/llvm/llvm-project/pull/146701
https://github.com/llvm/llvm-project/pull/141106
___
cfe-commits mailing list
cfe-commi
22 matches
Mail list logo
