kuilpd wrote:
> One big behavioral difference between your `CreateValueObjectFromValue` VO's
> and the `CreateValueObjectFromAPInt` ones is that you set the child address
> type to invalid, but the APInt one sets it to "load". That's fine so long as
> the Value only holds ints and not pointer
kuilpd wrote:
I'm trying here an alternative way of creating a const `ValueObject`. The way
it's currently done with `CreateValueObjectFromAPInt` is getting its data bytes
and sending them to `ValueObject::CreateValueObjectFromData`, which creates a
`ValueObjectConstResult` with `ValueType::H
https://github.com/kuilpd created
https://github.com/llvm/llvm-project/pull/151350
Add `ValueObject::CreateValueObjectFromScalar` function and adjust
`Scalar::GetData` to be able to both extend and truncate the data bytes in
Scalar to a desired size.
>From ff14392e82fb5658c87b4376551a0dc366b
kuilpd wrote:
> > single interface to traverse the AST tree:
>
> That's the part that would change in this setup. Instead of one API, we'd
> have two: `EvaluateValueNode()` and `EvaluateScalarNode()`, and we'd have two
> node hierarchies: ValueNode and ScalarNode. MemberOfNode would be a Value
kuilpd wrote:
> We can definitely add functions to covert (directly) between Scalars and
> ValueObjects (in fact, I think the only reason that the APInt overloads
> currently exists is because of the initial attempt to upstream the DIL
> implementation).
Ah, I didn't know that, I think I joi
kuilpd wrote:
> The process for that is
> [here](https://llvm.org/docs/GitHub.html#backporting-fixes-to-the-release-branches),
> though it's a bit unfortunate that a week has passed since then (I was OOO
> this week so I couldn't reply sooner). At this point, I'm no longer sure it
> makes sen
kuilpd wrote:
> It looks like this just barely didn't make it into the 21.x release branch.
> Do we want to cherry-pick that over? I think it would be a good way to flush
> out any issues...
I think so too, this and #149117. Do we just create a PR with the same changes
into `release/21.x` bra
kuilpd wrote:
> say that values retain their width and signedness, but then get converted
> into the wider width using C-like rules. We already have this implemented
> inside the Scalar class (which wraps APInt), so this would be best in terms
> of code reuse, and it would produce few surprise
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/147064
>From cf1f908360399ac51770d9fb7e1dac03eceab0e9 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Thu, 3 Jul 2025 19:34:17 +0500
Subject: [PATCH 1/2] [LLDB] *WIP* Add scalar literal node and binary addition
---
l
https://github.com/kuilpd closed
https://github.com/llvm/llvm-project/pull/147955
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
kuilpd wrote:
Added a test without debug info and you're right, it fails without this fix.
https://github.com/llvm/llvm-project/pull/147955
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-c
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/147955
>From 6b72ecb0f25b34ca112220e8587ef7fea46a38dd Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Thu, 10 Jul 2025 17:45:15 +0500
Subject: [PATCH 1/2] [LLDB] Check comp_unit before accessing it in DIL
---
lldb/so
kuilpd wrote:
> It's pretty much an accident we hit this in the test suite. Could you create
> a dedicated test for this. I guess the scenario is "running 'frame var' in a
> frame without debug info" (?)
No debug information at all? Or test the same `settings set
symbols.enable-external-looku
kuilpd wrote:
I addressed `lldb-shell-subprocess` tests failing in #147955 , but there's
still 2 data formatter tests failing, not sure what's happening there yet.
https://github.com/llvm/llvm-project/pull/147887
___
lldb-commits mailing list
lldb-com
kuilpd wrote:
`lldb-shell-subprocess` tests were failing because they add a setting `settings
set symbols.enable-external-lookup false`, which disables resolving variables
for compile units, but still marks them as resolved, so
`stack_frame->GetSymbolContext(lldb::eSymbolContextCompUnit)` just
https://github.com/kuilpd created
https://github.com/llvm/llvm-project/pull/147955
Check `symbol_context.comp_unit` before accessing it to avoid `nullptr`
dereferencing.
>From 6b72ecb0f25b34ca112220e8587ef7fea46a38dd Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Thu, 10 Jul 2025 17:45:15 +
kuilpd wrote:
> but I can also imagine doing something like python's "arbitrary width"
> integers.
Isn't this basically `llvm::APInt` class? We could just disregard every
integer's type, add their values as `APInt` and return the result with a
maximum width integer type. I kind of like this p
kuilpd wrote:
> We could, but I'm not sure if that's the most important question right now.
> The whole BasicType concept is very C-like. There is no "unsigned long long"
> basic type in swift (or pretty much any other language). While you could say
> that the function returns the langauge's e
kuilpd wrote:
@labath @cmtice @jimingham @asl
This is a draft with some potential changes I'd like to discuss regarding how
to handle the type system of constant literals.
I'm also trying to demonstrate how they interact further with other values in a
binary addition node. A lot of the code is
https://github.com/kuilpd created
https://github.com/llvm/llvm-project/pull/147064
A draft to discuss scalar literal node implementation
>From cf1f908360399ac51770d9fb7e1dac03eceab0e9 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Thu, 3 Jul 2025 19:34:17 +0500
Subject: [PATCH] [LLDB] *WIP*
kuilpd wrote:
Alright, thank you!
https://github.com/llvm/llvm-project/pull/146094
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
kuilpd wrote:
@Michael137
If I add a non-static member to that struct, would dsymutil keep the static
member debug info as well?
https://github.com/llvm/llvm-project/pull/146094
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.
kuilpd wrote:
> This might be isolated to dsyms (i remember dsymutil stripping some static
> inlines, but i forget exactly in which cases).
This is very likely the case, but I don't have a machine to debug this on.
Could we just skip this test case?
https://github.com/llvm/llvm-project/pull/1
https://github.com/kuilpd closed
https://github.com/llvm/llvm-project/pull/146094
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
kuilpd wrote:
> I'm not sure that's the right thing to do -- if there are multiple matches,
> how can we know we picked the one that the user wanted to see?
> What might matter for performance is, if returning false/nullptr here causes
> the implementation to perform the lookup at a larger (mor
kuilpd wrote:
I did some benchmarks of DIL on Unreal Engine 5 (thousands of variables to
search through) and noticed that our current variable lookup implementation is
~10 times slower than it was in `lldb-eval`, especially when it comes to global
variables in other files.
I looked into it and
https://github.com/kuilpd created
https://github.com/llvm/llvm-project/pull/146094
Remove unused code and unnecessary function calls, optimize global variable
search.
Add more test cases.
>From b69070a717fa80058af475397dae7a41f172c580 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Tue, 24 J
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/144557
>From 49a615d48433dabc6f05848f40e38601222efe38 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Tue, 17 Jun 2025 21:06:49 +0500
Subject: [PATCH 1/2] [LLDB] Add negative number parsing to DIL
---
lldb/source/Val
https://github.com/kuilpd created
https://github.com/llvm/llvm-project/pull/144557
None
>From 49a615d48433dabc6f05848f40e38601222efe38 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Tue, 17 Jun 2025 21:06:49 +0500
Subject: [PATCH] [LLDB] Add negative number parsing to DIL
---
lldb/source/V
https://github.com/kuilpd closed
https://github.com/llvm/llvm-project/pull/141422
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -62,7 +62,7 @@ def test_subscript(self):
self.expect(
"frame var 'int_arr[-1]'",
error=True,
-substrs=["unrecognized token"],
+substrs=["failed to parse integer constant"],
kuilpd wrote:
Should I make
kuilpd wrote:
@labath @jimingham
Just to clarify, do we change `-` to `:` now in this PR or later, after we
replace `frame var` with DIL?
https://github.com/llvm/llvm-project/pull/141422
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https
https://github.com/kuilpd created
https://github.com/llvm/llvm-project/pull/141422
None
>From b093c5fb20c56251c61235c748b673ce59840173 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Tue, 20 May 2025 17:58:01 +0500
Subject: [PATCH] [LLDB] Add BitExtraction node to DIL
---
lldb/include/lldb/
https://github.com/kuilpd closed
https://github.com/llvm/llvm-project/pull/141102
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kuilpd edited
https://github.com/llvm/llvm-project/pull/141102
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/141102
>From 5210b8b00dfd05d092b3519cbb0a5480b3abe534 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Thu, 22 May 2025 16:15:11 +0500
Subject: [PATCH 1/2] [LLDB] Add array subscription and integer parsing to DIL
(#138
https://github.com/kuilpd edited
https://github.com/llvm/llvm-project/pull/141102
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
kuilpd wrote:
@labath
This code
```
llvm::Expected num_children = synthetic->GetNumChildren(child_idx
+ 1);
```
didn't work for `std::vector` on Windows on AArch64, got a buildbot error
there: https://lab.llvm.org/buildbot/#/builders/141/builds/8906
```
AssertionError: ':1:7: array index
https://github.com/kuilpd created
https://github.com/llvm/llvm-project/pull/141102
None
>From ad2c40ea689c71074237287989fa7ae01bd428e4 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Thu, 22 May 2025 16:15:11 +0500
Subject: [PATCH 1/2] [LLDB] Add array subscription and integer parsing to DIL
https://github.com/kuilpd closed
https://github.com/llvm/llvm-project/pull/141059
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kuilpd created
https://github.com/llvm/llvm-project/pull/141059
Reverts llvm/llvm-project#138551
>From b2e110036df39bb33163b5cd6c8dacf9253b6b33 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Thu, 22 May 2025 17:29:24 +0500
Subject: [PATCH] Revert "[LLDB] Add array subscrip
https://github.com/kuilpd closed
https://github.com/llvm/llvm-project/pull/138551
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -272,4 +272,67 @@ Interpreter::Visit(const UnaryOpNode *node) {
m_expr, "invalid ast: unexpected binary operator", node->GetLocation());
}
+llvm::Expected
+Interpreter::Visit(const ArraySubscriptNode *node) {
+ auto lhs_or_err = Evaluate(node->GetBase());
+ if (!lhs
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/138551
>From ad204cdfd226ca2a886c5475775fe67b29a70926 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Wed, 30 Apr 2025 22:03:50 +0500
Subject: [PATCH 1/7] [LLDB] Add array subscription and integer parsing to DIL
---
@@ -272,4 +272,67 @@ Interpreter::Visit(const UnaryOpNode *node) {
m_expr, "invalid ast: unexpected binary operator", node->GetLocation());
}
+llvm::Expected
+Interpreter::Visit(const ArraySubscriptNode *node) {
+ auto lhs_or_err = Evaluate(node->GetBase());
+ if (!lhs
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/138551
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-se
@@ -111,7 +111,42 @@ ASTNodeUP DILParser::ParseUnaryExpression() {
llvm_unreachable("invalid token kind");
}
}
- return ParsePrimaryExpression();
+ return ParsePostfixExpression();
+}
+
+// Parse a postfix_expression.
+//
+// postfix_expression:
+//primary_ex
@@ -272,4 +272,67 @@ Interpreter::Visit(const UnaryOpNode *node) {
m_expr, "invalid ast: unexpected binary operator", node->GetLocation());
}
+llvm::Expected
+Interpreter::Visit(const ArraySubscriptNode *node) {
+ auto lhs_or_err = Evaluate(node->GetBase());
+ if (!lhs
@@ -111,7 +111,42 @@ ASTNodeUP DILParser::ParseUnaryExpression() {
llvm_unreachable("invalid token kind");
}
}
- return ParsePrimaryExpression();
+ return ParsePostfixExpression();
+}
+
+// Parse a postfix_expression.
+//
+// postfix_expression:
+//primary_ex
kuilpd wrote:
I think I addressed everything I could, please take a look again.
https://github.com/llvm/llvm-project/pull/138551
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -272,4 +272,67 @@ Interpreter::Visit(const UnaryOpNode *node) {
m_expr, "invalid ast: unexpected binary operator", node->GetLocation());
}
+llvm::Expected
+Interpreter::Visit(const ArraySubscriptNode *node) {
+ auto lhs_or_err = Evaluate(node->GetBase());
+ if (!lhs
@@ -272,4 +272,67 @@ Interpreter::Visit(const UnaryOpNode *node) {
m_expr, "invalid ast: unexpected binary operator", node->GetLocation());
}
+llvm::Expected
+Interpreter::Visit(const ArraySubscriptNode *node) {
+ auto lhs_or_err = Evaluate(node->GetBase());
+ if (!lhs
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/138551
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-se
https://github.com/kuilpd closed
https://github.com/llvm/llvm-project/pull/139567
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
kuilpd wrote:
Thank you!
https://github.com/llvm/llvm-project/pull/139567
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kuilpd ready_for_review
https://github.com/llvm/llvm-project/pull/139567
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
kuilpd wrote:
@felipepiovezan
I don't have a machine to run ObjC tests on, could you apply this patch and see
if it fixes the issue in #135843 ?
https://github.com/llvm/llvm-project/pull/139567
___
lldb-commits mailing list
lldb-commits@lists.llvm.or
https://github.com/kuilpd created
https://github.com/llvm/llvm-project/pull/139567
Attempt an ObjC incomplete type fix even if `GetDereferencedType` returns an
error.
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
https://github.com/kuilpd closed
https://github.com/llvm/llvm-project/pull/135843
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kuilpd edited
https://github.com/llvm/llvm-project/pull/135843
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/135843
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-se
@@ -2794,47 +2794,31 @@ ValueObjectSP ValueObject::Dereference(Status &error) {
if (m_deref_valobj)
return m_deref_valobj->GetSP();
- const bool is_pointer_or_reference_type = IsPointerOrReferenceType();
- if (is_pointer_or_reference_type) {
-bool omit_empty_base_c
kuilpd wrote:
> Because I wanted to avoid this getting bogged down in the discussion about
> the types of numbers. I don't really mind the "extra capability" of indexing
> an array with a another variable. The part I have problem with is the
> precedent it sets about the representation of numb
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/138551
>From cfe7359bd16c1e87932e2ebb8bcdfc88130e9729 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Wed, 30 Apr 2025 22:03:50 +0500
Subject: [PATCH 1/4] [LLDB] Add array subscription and integer parsing to DIL
---
kuilpd wrote:
> I don't have an answer to that, but I do know that it's possible to index
> pointers in the current implementation. I suggest checking out how it
> achieves that and seeing if it can be translated to here.
I found `GetSyntheticArrayMember`, hopefully this is the one you're refe
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/138551
>From cfe7359bd16c1e87932e2ebb8bcdfc88130e9729 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Wed, 30 Apr 2025 22:03:50 +0500
Subject: [PATCH 1/3] [LLDB] Add array subscription and integer parsing to DIL
---
@@ -24,6 +28,8 @@ qualified_id = ["::"] [nested_name_specifier] unqualified_id
identifier = ? C99 Identifier ? ;
+numeric_literal = ? C99 Integer constant ? ;
kuilpd wrote:
Yeah, `0b...` and `0o...` formats supported here are missing from C99. How
should I
kuilpd wrote:
> Apart from the pointer indexing question, this PR also opens the question of
> "how should the numbers be represented". Here you represent them as
> ValueObjects, which means you have to give them types, which means you have
> to find a type system for them, ...
Why is that a
@@ -280,6 +311,52 @@ void DILParser::BailOut(const std::string &error, uint32_t
loc,
m_dil_lexer.ResetTokenIdx(m_dil_lexer.NumLexedTokens() - 1);
}
+// Parse a numeric_literal.
+//
+// numeric_literal:
+//? Token::numeric_constant ?
+//
+ASTNodeUP DILParser::ParseNumer
@@ -111,7 +111,36 @@ ASTNodeUP DILParser::ParseUnaryExpression() {
llvm_unreachable("invalid token kind");
}
}
- return ParsePrimaryExpression();
+ return ParsePostfixExpression();
+}
+
+// Parse a postfix_expression.
+//
+// postfix_expression:
+//primary_ex
kuilpd wrote:
> Swift doesn't have pointers really. It does pass some things by value (called
> structs) and others by reference (called classes), but it doesn't let you
> know how. So this ambiguity between "pointer to object" and "pointer to
> contiguous buffer of objects" doesn't come up.
kuilpd wrote:
> I don't have an answer to that, but I do know that it's possible to index
> pointers in the current implementation. I suggest checking out how it
> achieves that and seeing if it can be translated to here.
Ah, I will look into this further, thanks.
https://github.com/llvm/llvm
kuilpd wrote:
One thing I'm not sure about here: will converting array type to a pointer,
adding the index and then dereferencing work for Swift?
I tried just doing `base->GetChildAtIndex(index)`, but it doesn't work when the
base is a pointer and it also returns an error when index is out of b
https://github.com/kuilpd created
https://github.com/llvm/llvm-project/pull/138551
None
>From cfe7359bd16c1e87932e2ebb8bcdfc88130e9729 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Wed, 30 Apr 2025 22:03:50 +0500
Subject: [PATCH] [LLDB] Add array subscription and integer parsing to DIL
---
https://github.com/kuilpd closed
https://github.com/llvm/llvm-project/pull/137688
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
kuilpd wrote:
@labath
Is this okay to merge now?
https://github.com/llvm/llvm-project/pull/137688
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/135843
>From 7cca4bf228ab2b882a1a6487eb24948cba9e5b12 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Wed, 16 Apr 2025 00:30:51 +0500
Subject: [PATCH 1/5] [lldb][TypeSystemClang] Add a function
`IsValidDereferenceType
@@ -88,7 +88,7 @@ def cleanup():
self.expect(
"frame variable *number_not_engaged",
error=True,
-substrs=["not a pointer or reference type"],
+substrs=["dereference failed: not a"],
kuilpd wrote:
I had a
https://github.com/kuilpd ready_for_review
https://github.com/llvm/llvm-project/pull/137688
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/135843
>From 7cca4bf228ab2b882a1a6487eb24948cba9e5b12 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Wed, 16 Apr 2025 00:30:51 +0500
Subject: [PATCH 1/4] [lldb][TypeSystemClang] Add a function
`IsValidDereferenceType
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/137688
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-se
https://github.com/kuilpd closed
https://github.com/llvm/llvm-project/pull/134428
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
kuilpd wrote:
If I apply code formatter to the test, it breaks lines and no longer works.
Should I rewrite it without using inline tests?
https://github.com/llvm/llvm-project/pull/137688
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https:
@@ -232,4 +263,105 @@ Interpreter::Visit(const IdentifierNode *node) {
return identifier;
}
-} // namespace lldb_private::dil
+llvm::Expected
+Interpreter::Visit(const UnaryOpNode *node) {
+ FlowAnalysis rhs_flow(
+ /* address_of_is_pending */ node->kind() == UnaryOpKi
https://github.com/kuilpd created
https://github.com/llvm/llvm-project/pull/137688
`ValueObject::AddressOf()` used to return address as a value which has it's own
address, allowing to do `value.AddressOf().AddressOf()`.
This patch makes the return address a simple const value.
>From 5108154682
https://github.com/kuilpd approved this pull request.
I see, makes sense now, thank you.
https://github.com/llvm/llvm-project/pull/137311
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-com
https://github.com/kuilpd edited
https://github.com/llvm/llvm-project/pull/137311
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -2202,6 +2202,45 @@ void ValueObject::GetExpressionPath(Stream &s,
}
}
+// Return the alternate value (synthetic if the input object is non-synthetic
+// and otherwise) this is permitted by the expression path options.
+static ValueObjectSP GetAlternateValue(
+ValueOb
kuilpd wrote:
> It's also possible that the implementation of Dereference is just too
> persistent. I think it's doing too much. I've created
> https://github.com/llvm/llvm-project/pull/137311 which I think is a better
> way to approach dereferencing (BTW, I think you'll need to do something
https://github.com/kuilpd edited
https://github.com/llvm/llvm-project/pull/137311
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kuilpd commented:
So the difference is that if `value->Dereference` fails, the user should try to
manually dereference a synthetic value?
https://github.com/llvm/llvm-project/pull/137311
___
lldb-commits mailing list
lldb-commits@li
kuilpd wrote:
@labath
Should I move the check for `void *` to `TypeSystemClang::GetDereferencedType`
in the other PR?
https://github.com/llvm/llvm-project/pull/134428
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cg
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/135843
>From 08834d47602b0df46e43678c08b3902d45145871 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Wed, 16 Apr 2025 00:30:51 +0500
Subject: [PATCH 1/3] [lldb][TypeSystemClang] Add a function
`IsValidDereferenceType
https://github.com/kuilpd ready_for_review
https://github.com/llvm/llvm-project/pull/135843
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
kuilpd wrote:
@labath @jimingham
This is just one way to allow C/C++ to dereference arrays and let other
languages decide on which types they allow to dereference.
I tried making a `GetDereferencedType` function in TypeSystem, but it doesn't
really need to do anything right now, everything is
https://github.com/kuilpd created
https://github.com/llvm/llvm-project/pull/135843
Add a function `IsValidDereferenceType` to TypeSystem.
TypeSystemClang now allows arrays to be dereferenced.
>From 889900ece6cccfb7cd2d8d16706bc2d5db18c381 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Wed, 1
@@ -18,6 +18,22 @@
namespace lldb_private::dil {
+static lldb::ValueObjectSP
+ArrayToPointerConversion(lldb::ValueObjectSP valobj,
+ std::shared_ptr ctx) {
+ assert(valobj->IsArrayType() &&
+ "an argument to array-to-pointer conversion must be
@@ -18,6 +18,22 @@
namespace lldb_private::dil {
+static lldb::ValueObjectSP
+ArrayToPointerConversion(lldb::ValueObjectSP valobj,
+ std::shared_ptr ctx) {
+ assert(valobj->IsArrayType() &&
+ "an argument to array-to-pointer conversion must be
@@ -232,4 +263,105 @@ Interpreter::Visit(const IdentifierNode *node) {
return identifier;
}
-} // namespace lldb_private::dil
+llvm::Expected
+Interpreter::Visit(const UnaryOpNode *node) {
+ FlowAnalysis rhs_flow(
+ /* address_of_is_pending */ node->kind() == UnaryOpKi
@@ -232,4 +263,105 @@ Interpreter::Visit(const IdentifierNode *node) {
return identifier;
}
-} // namespace lldb_private::dil
+llvm::Expected
+Interpreter::Visit(const UnaryOpNode *node) {
+ FlowAnalysis rhs_flow(
+ /* address_of_is_pending */ node->kind() == UnaryOpKi
1 - 100 of 175 matches
Mail list logo
