[Lldb-commits] [lldb] [LLDB/Coredump] Only take the Pthread from stack start to the stackpointer + red_zone (PR #92002)

2024-05-13 Thread via lldb-commits


@@ -3857,8 +3857,8 @@ thread_result_t Process::RunPrivateStateThread(bool 
is_secondary_thread) {
 // case we should tell it to stop doing that.  Normally, we don't NEED
 // to do that because we will next close the communication to the stub
 // and that will get it to shut down.  But there are remote debugging
-// cases where relying on that side-effect causes the shutdown to be 
-// flakey, so we should send a positive signal to interrupt the wait. 
+// cases where relying on that side-effect causes the shutdown to be
+// flakey, so we should send a positive signal to interrupt the wait.

jeffreytan81 wrote:

Undo these changes

https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB/Coredump] Only take the Pthread from stack start to the stackpointer + red_zone (PR #92002)

2024-05-13 Thread via lldb-commits


@@ -36,17 +35,37 @@ def verify_core_file(
 self.assertEqual(module_file_name, expected_file_name)
 self.assertEqual(module.GetUUIDString(), expected.GetUUIDString())
 
+red_zone = process.GetTarget().GetStackRedZoneSize()
 for thread_idx in range(process.GetNumThreads()):
 thread = process.GetThreadAtIndex(thread_idx)
 self.assertTrue(thread.IsValid())
 thread_id = thread.GetThreadID()
 self.assertIn(thread_id, expected_threads)
+frame = thread.GetFrameAtIndex(0)
+sp_region = lldb.SBMemoryRegionInfo()
+sp = frame.GetSP()
+err = process.GetMemoryRegionInfo(sp, sp_region)
+self.assertTrue(err.Success(), err.GetCString())
+error = lldb.SBError()
+# Try to read at the end of the stack red zone and succeed
+process.ReadMemory(sp_region.GetRegionEnd() - 1, 1, error)
+self.assertTrue(error.Success(), error.GetCString())
+# Try to read just past the red zone and fail
+process.ReadMemory(sp_region.GetRegionEnd() + 1, 1, error)
+# Try to read from the base of the stack
+self.assertTrue(error.Fail(), error.GetCString())
+self.assertTrue(stacks_to_sps_map.__contains__(thread_id), 
"stacks_to_sps_map does not contain thread_idx: %d" % thread_idx)

jeffreytan81 wrote:

Use `self.assertIn()`

https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB/Coredump] Only take the Pthread from stack start to the stackpointer + red_zone (PR #92002)

2024-05-13 Thread via lldb-commits

https://github.com/jeffreytan81 edited 
https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB/Coredump] Only take the Pthread from stack start to the stackpointer + red_zone (PR #92002)

2024-05-13 Thread via lldb-commits


@@ -6410,12 +6410,20 @@ GetCoreFileSaveRangesStackOnly(Process ,
 if (!reg_ctx_sp)
   continue;
 const addr_t sp = reg_ctx_sp->GetSP();
+const size_t red_zone = process.GetABI()->GetRedZoneSize();
 lldb_private::MemoryRegionInfo sp_region;
 if (process.GetMemoryRegionInfo(sp, sp_region).Success()) {
   // Only add this region if not already added above. If our stack pointer
   // is pointing off in the weeds, we will want this range.
-  if (stack_bases.count(sp_region.GetRange().GetRangeBase()) == 0)
+  if (stack_bases.count(sp_region.GetRange().GetRangeBase()) == 0) {
+// Take only the start of the stack to the stack pointer and include 
the redzone.
+// Because stacks grow 'down' to include the red_zone we have to 
subtract it from the sp.
+const size_t stack_head = (sp - red_zone);

jeffreytan81 wrote:

Let's do some validation that `stack_head` is greater than range start in case 
`GetRedZoneSize` returns some bogus value.

https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB/Coredump] Only take the Pthread from stack start to the stackpointer + red_zone (PR #92002)

2024-05-13 Thread via lldb-commits


@@ -36,17 +35,37 @@ def verify_core_file(
 self.assertEqual(module_file_name, expected_file_name)
 self.assertEqual(module.GetUUIDString(), expected.GetUUIDString())
 
+red_zone = process.GetTarget().GetStackRedZoneSize()
 for thread_idx in range(process.GetNumThreads()):
 thread = process.GetThreadAtIndex(thread_idx)
 self.assertTrue(thread.IsValid())
 thread_id = thread.GetThreadID()
 self.assertIn(thread_id, expected_threads)
+frame = thread.GetFrameAtIndex(0)
+sp_region = lldb.SBMemoryRegionInfo()
+sp = frame.GetSP()
+err = process.GetMemoryRegionInfo(sp, sp_region)
+self.assertTrue(err.Success(), err.GetCString())
+error = lldb.SBError()
+# Try to read at the end of the stack red zone and succeed
+process.ReadMemory(sp_region.GetRegionEnd() - 1, 1, error)
+self.assertTrue(error.Success(), error.GetCString())
+# Try to read just past the red zone and fail
+process.ReadMemory(sp_region.GetRegionEnd() + 1, 1, error)
+# Try to read from the base of the stack

jeffreytan81 wrote:

1. For checking top of the stack + red zone, isn't it GetRegionBase() because 
stack grows toward lower address?
2. This function is used by not only stack only option but all options so I am 
not sure implementation details of stack-only dump uses red zone making sense 
here.
3. Even for stack-only dump, I am not sure this is testing anything related 
with red zone, it simply tests that dump does not contain memory outside its 
memory region...


https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB/Coredump] Only take the Pthread from stack start to the stackpointer + red_zone (PR #92002)

2024-05-13 Thread via lldb-commits


@@ -6410,12 +6410,20 @@ GetCoreFileSaveRangesStackOnly(Process ,
 if (!reg_ctx_sp)
   continue;
 const addr_t sp = reg_ctx_sp->GetSP();
+const size_t red_zone = process.GetABI()->GetRedZoneSize();
 lldb_private::MemoryRegionInfo sp_region;
 if (process.GetMemoryRegionInfo(sp, sp_region).Success()) {
   // Only add this region if not already added above. If our stack pointer
   // is pointing off in the weeds, we will want this range.
-  if (stack_bases.count(sp_region.GetRange().GetRangeBase()) == 0)
+  if (stack_bases.count(sp_region.GetRange().GetRangeBase()) == 0) {
+// Take only the start of the stack to the stack pointer and include 
the redzone.
+// Because stacks grow 'down' to include the red_zone we have to 
subtract it from the sp.
+const size_t stack_head = (sp - red_zone);
+const size_t stack_size = sp_region.GetRange().GetRangeEnd() - 
(stack_head);

jeffreytan81 wrote:

Any reason you need to quote `stack_head` into `(stack_head)`? 

https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB/Coredump] Only take the Pthread from stack start to the stackpointer + red_zone (PR #92002)

2024-05-13 Thread via lldb-commits

https://github.com/jeffreytan81 commented:

The changes looks good but the title and description should make it clear that 
we are only optimizing this for stack-only option.

https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB/Coredump] Only take the Pthread from stack start to the stackpointer + red_zone (PR #92002)

2024-05-13 Thread via lldb-commits


@@ -36,17 +35,37 @@ def verify_core_file(
 self.assertEqual(module_file_name, expected_file_name)
 self.assertEqual(module.GetUUIDString(), expected.GetUUIDString())
 
+red_zone = process.GetTarget().GetStackRedZoneSize()

jeffreytan81 wrote:

Is this used?

https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #90663)

2024-05-13 Thread via lldb-commits

jimingham wrote:

Can you take care of cleaning this up, this seems like a slightly complex patch 
and not in an area I'm familiar with.

Thanks!

Jim


> On May 13, 2024, at 6:35 PM, Zequan Wu ***@***.***> wrote:
> 
> 
> Reverting those two commits seems to have caused this build failure on Ubuntu:
> 
> You forgot to delete the newly added test 
> SymbolFile/DWARF/delayed-definition-die-searching.test in the reverting: 
> 37b8e5f 
> 
> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because you are on a team that was mentioned.
> 



https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #90663)

2024-05-13 Thread Zequan Wu via lldb-commits

ZequanWu wrote:

> Reverting those two commits seems to have caused this build failure on Ubuntu:

You forgot the delete the newly added test 
SymbolFile/DWARF/delayed-definition-die-searching.test in the reverting: 
https://github.com/llvm/llvm-project/commit/37b8e5feb1d065a7c474e6595bac6d2f65faeb51

https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #90663)

2024-05-13 Thread via lldb-commits

jimingham wrote:

Reverting those two commits seems to have caused this build failure on Ubuntu:

Step 4 (build) warnings: build (warnings)
../llvm-project/clang/lib/Lex/PPDirectives.cpp:548:28: warning: comparison of 
integers of different signs: 'unsigned int' and 'int' [-Wsign-compare]
1 warning generated.
../llvm-project/clang/lib/Frontend/TextDiagnostic.cpp:148:36: warning: 
comparison of integers of different signs: 'int' and 'unsigned int' 
[-Wsign-compare]
1 warning generated.
../llvm-project/llvm/lib/Target/AMDGPU/AMDGPUIGroupLP.cpp:1079:20: warning: 
comparison of integers of different signs: 'typename iterator_traits::difference_type' (aka 'int') and 'unsigned int' [-Wsign-compare]
../llvm-project/llvm/lib/Target/AMDGPU/AMDGPUIGroupLP.cpp:1089:24: warning: 
comparison of integers of different signs: 'typename iterator_traits::difference_type' (aka 'int') and 'unsigned int' [-Wsign-compare]
../llvm-project/llvm/lib/Target/AMDGPU/AMDGPUIGroupLP.cpp:1120:20: warning: 
comparison of integers of different signs: 'typename iterator_traits::difference_type' (aka 'int') and 'unsigned int' [-Wsign-compare]
../llvm-project/llvm/lib/Target/AMDGPU/AMDGPUIGroupLP.cpp:1130:24: warning: 
comparison of integers of different signs: 'typename iterator_traits::difference_type' (aka 'int') and 'unsigned int' [-Wsign-compare]
../llvm-project/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp:1107:7: 
warning: implicit conversion from 'long long' to 'const std::time_t' (aka 
'const long') changes value from -1096193779200 to -977118720 
[-Wconstant-conversion]
../llvm-project/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp:1109:7: 
warning: implicit conversion from 'long long' to 'const std::time_t' (aka 
'const long') changes value from 971890963199 to 1228354303 
[-Wconstant-conversion]
../llvm-project/lld/MachO/SyntheticSections.cpp:2063:25: warning: comparison of 
integers of different signs: 'int' and 'const uint32_t' (aka 'const unsigned 
int') [-Wsign-compare]
1 warning generated.

Step 6 (test) failure: build (failure)
clang: warning: argument unused during compilation: 
'-fmodules-cache-path=/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/lldb-test-build.noindex/module-cache-clang/lldb-shell'
 [-Wunused-command-line-argument]

Would you mind taking a look, this is not my area of llvm...

https://lab.llvm.org/buildbot/#/builders/17/builds/53025

Thanks!

Jim

> On May 13, 2024, at 6:22 PM, Zequan Wu ***@***.***> wrote:
> 
> 
> your commit deleted that file I think, I added it back when I did the revert 
> (possibly a mistake)... It passes on my macOS system but is failing on Ubuntu 
> after the revert. I think I'll just disable it for now.
> 
> This change adds the new test, so deleting it as part of the reverting is 
> expected.
> 
> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because you are on a team that was mentioned.
> 



https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [llvm] [lldb] Refactor string manipulation in Debugger.cpp (#91209) (PR #91880)

2024-05-13 Thread Youngsuk Kim via lldb-commits

JOE1994 wrote:

> We usually don't grant exclusive rights to work on an issue in the project, 
> since individual priorities may always change and people might loose interest 
> in an issue. Typically this kind of conflict doesn't happen very often 
> either. 

I understand that, but just for "good first issue"s,
I think it's desirable to allow 1 week to the person (likely a newcomer to the 
project) who first requested to be assigned to it
(the 1st step in the "good first issue" instructions also suggests this).

The user who initially asked to be assigned to the linked issue doesn't have 
"assign" access, and was likely waiting to get assigned. Assigning the issue to 
another user without any explanation or ping can be emotionally frustrating to 
the new user.

I've seen a similar conflict around a "good first issue" get heated in 
(`#84207`).

https://github.com/llvm/llvm-project/pull/91880
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #90663)

2024-05-13 Thread Zequan Wu via lldb-commits

ZequanWu wrote:

> your commit deleted that file I think, I added it back when I did the revert 
> (possibly a mistake)...  It passes on my macOS system but is failing on 
> Ubuntu after the revert.  I think I'll just disable it for now.

This change adds the new test, so deleting it as part of the reverting is 
expected.

https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] e6b2197 - Revert a test that was failing after a previous reversion.

2024-05-13 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2024-05-13T18:18:40-07:00
New Revision: e6b2197a89f5d6d0f56a03c03b8afda561eee899

URL: 
https://github.com/llvm/llvm-project/commit/e6b2197a89f5d6d0f56a03c03b8afda561eee899
DIFF: 
https://github.com/llvm/llvm-project/commit/e6b2197a89f5d6d0f56a03c03b8afda561eee899.diff

LOG: Revert a test that was failing after a previous reversion.

This test was modified as part of the commit:

9a7262c2601874e5aa64c5db19746770212d4b44

but without that patch this test is failing.  Remove the test for now
till the issue with the original patch can be sorted out.

Added: 


Modified: 


Removed: 
lldb/test/Shell/SymbolFile/DWARF/delayed-definition-die-searching.test



diff  --git 
a/lldb/test/Shell/SymbolFile/DWARF/delayed-definition-die-searching.test 
b/lldb/test/Shell/SymbolFile/DWARF/delayed-definition-die-searching.test
deleted file mode 100644
index d253981b498c8..0
--- a/lldb/test/Shell/SymbolFile/DWARF/delayed-definition-die-searching.test
+++ /dev/null
@@ -1,36 +0,0 @@
-# Test definition DIE searching is delayed until complete type is required.
-
-# UNSUPPORTED: system-windows
-
-# RUN: split-file %s %t
-# RUN: %clangxx_host %t/main.cpp %t/t1_def.cpp -gdwarf -o %t.out
-# RUN: %lldb -b %t.out -s %t/lldb.cmd | FileCheck %s
-
-# CHECK: (lldb) p v1
-# CHECK: DWARFASTParserClang::ParseTypeFromDWARF{{.*}}DW_TAG_structure_type 
(DW_TAG_structure_type) name = 't2'
-# CHECK: DWARFASTParserClang::ParseTypeFromDWARF{{.*}}DW_TAG_structure_type 
(DW_TAG_structure_type) name = 't1'
-# CHECK: DW_TAG_structure_type (DW_TAG_structure_type) 't2' resolving 
forward declaration...
-# CHECK: (t2)  {}
-# CHECK: (lldb) p v2
-# CHECK: DWARFASTParserClang::ParseTypeFromDWARF{{.*}}DW_TAG_structure_type 
(DW_TAG_structure_type) name = 't1'
-# CHECK: DW_TAG_structure_type (DW_TAG_structure_type) 't1' resolving forward 
declaration...
-
-#--- lldb.cmd
-log enable dwarf comp
-p v1
-p v2
-
-#--- main.cpp
-template
-struct t2 {
-};
-struct t1;
-t2 v1; // this CU doesn't have definition DIE for t1, but only declaration 
DIE for it.
-int main() {
-}
-
-#--- t1_def.cpp
-struct t1 { // this CU contains definition DIE for t1.
-  int x;
-};
-t1 v2;



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #90663)

2024-05-13 Thread via lldb-commits

jimingham wrote:

BTW, do you know what's up with this test:

SymbolFile/DWARF/delayed-definition-die-searching.test

your commit deleted that file I think, I added it back when I did the revert 
(possibly a mistake)...  It passes on my macOS system but is failing on Ubuntu 
after the revert.  I think I'll just disable it for now.

Jim


> On May 13, 2024, at 6:09 PM, Jim Ingham ***@***.***> wrote:
> 
>> 
>> 
>> 
>>> On May 13, 2024, at 6:04 PM, Zequan Wu ***@***.***> wrote:
>>> 
>>> 
>>> I was able to reproduce the failure of these three:
>>> 
>>> lldb-api :: lang/c/forward/TestForwardDeclaration.py
>>> lldb-api :: lang/cpp/unique-types3/TestUniqueTypes3.py
>>> lldb-api :: types/TestRecursiveTypes.py
>>> 
>>> locally. Reverting this patch and a7eff59 
>>> 
>>>  which depended on it made the failure go away.
>>> 
>>> I reverted the patches for now to get the bots clean.
>>> 
>>> Thanks. Can you provide instructions to repro the failure locally?
>>> 
>> I didn't do anything out of the ordinary.  I'm on macOS Sonoma 14.4.1, with 
>> the latest Xcode(15.3).  I ran the CMakery this way:
>> 
>> cmake -B `pwd`/all-in-one -G Ninja -C 
>> `pwd`/llvm-project/lldb/cmake/caches/Apple-lldb-base.cmake 
>> -DLLVM_ENABLE_PROJECTS="clang;lldb" 
>> -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;compiler-rt;libunwind" 
>> -DLIBCXX_INCLUDE_TESTS=OFF  -DCMAKE_BUILD_TYPE=Debug 
>> -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING=12.3  -DLLDB_BUILD_FRAMEWORK=YES  
>> -DCMAKE_CXX_STANDARD:STRING=17 llvm-project/llvm
>> 
>> Then:
>> 
>> $ cd all-in-one
>> $ ninja check-lldb
>> 
>> and got the failure.
>> 
>> Jim
>> 
>> 
>>> @ZequanWu  in the future, if one of your 
>>> commits break a bot, make sure to revert it immediately, you can always 
>>> re-land it later with a fix or an explanation why it wasn't your commit 
>>> that broke the bots. Reverting a commit is cheap, red bots are expensive :-)
>>> 
>>> Will do.
>>> 
>>> —
>>> Reply to this email directly, view it on GitHub 
>>> , 
>>> or unsubscribe 
>>> .
>>> You are receiving this because you are on a team that was mentioned.
>>> 
>> 
>> 



https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #90663)

2024-05-13 Thread via lldb-commits

jimingham wrote:



> On May 13, 2024, at 6:04 PM, Zequan Wu ***@***.***> wrote:
> 
> 
> I was able to reproduce the failure of these three:
> 
> lldb-api :: lang/c/forward/TestForwardDeclaration.py
> lldb-api :: lang/cpp/unique-types3/TestUniqueTypes3.py
> lldb-api :: types/TestRecursiveTypes.py
> 
> locally. Reverting this patch and a7eff59 
> 
>  which depended on it made the failure go away.
> 
> I reverted the patches for now to get the bots clean.
> 
> Thanks. Can you provide instructions to repro the failure locally?
> 
I didn't do anything out of the ordinary.  I'm on macOS Sonoma 14.4.1, with the 
latest Xcode(15.3).  I ran the CMakery this way:

cmake -B `pwd`/all-in-one -G Ninja -C 
`pwd`/llvm-project/lldb/cmake/caches/Apple-lldb-base.cmake 
-DLLVM_ENABLE_PROJECTS="clang;lldb" 
-DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;compiler-rt;libunwind" 
-DLIBCXX_INCLUDE_TESTS=OFF  -DCMAKE_BUILD_TYPE=Debug 
-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING=12.3  -DLLDB_BUILD_FRAMEWORK=YES  
-DCMAKE_CXX_STANDARD:STRING=17 llvm-project/llvm

Then:

$ cd all-in-one
$ ninja check-lldb

and got the failure.

Jim


> @ZequanWu  in the future, if one of your commits 
> break a bot, make sure to revert it immediately, you can always re-land it 
> later with a fix or an explanation why it wasn't your commit that broke the 
> bots. Reverting a commit is cheap, red bots are expensive :-)
> 
> Will do.
> 
> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because you are on a team that was mentioned.
> 



https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #90663)

2024-05-13 Thread Zequan Wu via lldb-commits

ZequanWu wrote:

> I was able to reproduce the failure of these three:
> 
> lldb-api :: lang/c/forward/TestForwardDeclaration.py
> lldb-api :: lang/cpp/unique-types3/TestUniqueTypes3.py
> lldb-api :: types/TestRecursiveTypes.py
>
> locally. Reverting this patch and 
> https://github.com/llvm/llvm-project/commit/a7eff59f78f08f8ef0487dfe2a136fb311af4fd0
>  which depended on it made the failure go away.
> 
> I reverted the patches for now to get the bots clean.

Thanks. Can you provide instructions to repro the failure locally?

> @ZequanWu in the future, if one of your commits break a bot, make sure to 
> revert it immediately, you can always re-land it later with a fix or an 
> explanation why it wasn't your commit that broke the bots. Reverting a commit 
> is cheap, red bots are expensive :-)

Will do. 

https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #90663)

2024-05-13 Thread Adrian Prantl via lldb-commits

adrian-prantl wrote:

@ZequanWu in the future, if one of your commits break a bot, make sure to 
revert it immediately, you can always re-land it later with a fix or an 
explanation why it wasn't your commit that broke the bots. Reverting a commit 
is cheap, red bots are expensive :-)

https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [llvm] [lldb] Refactor string manipulation in Debugger.cpp (#91209) (PR #91880)

2024-05-13 Thread Adrian Prantl via lldb-commits

adrian-prantl wrote:

> A new user already asked to be assigned to work on #91209 2 days ago in the 
> comments. **I think that user deserves an opportunity to work on the issue**.
> 
> Next time when you see a **"good first issue"** which a new user had already 
> asked to get assigned to, please assign it to the new user.

We usually don't grant exclusive rights to work on an issue in the project, 
since individual priorities may always change and people might loose interest 
in an issue. Typically this kind of conflict doesn't happen very often either. 
For an issue as trivial as this one, it might be better to just open a PR 
straight ahead instead of waiting for the issue to be assigned to someone 
(which is also something we typically don't do in the project for the 
aforementioned reasons).

https://github.com/llvm/llvm-project/pull/91880
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #90663)

2024-05-13 Thread via lldb-commits

jimingham wrote:

I was able to reproduce the failure of these three:

  lldb-api :: lang/c/forward/TestForwardDeclaration.py
  lldb-api :: lang/cpp/unique-types3/TestUniqueTypes3.py
  lldb-api :: types/TestRecursiveTypes.py

locally.  Reverting this patch and a7eff59f78f08f8ef0487dfe2a136fb311af4fd0 
which depended on it made the failure go away.

I reverted the patches for now to get the bots clean.



https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 70de9b2 - Revert "[lldb][DWARF] Do not complete type from declaration die. (#91799)"

2024-05-13 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2024-05-13T17:47:49-07:00
New Revision: 70de9b21cbdeb1297108c4ee520b8f6dbd6496a7

URL: 
https://github.com/llvm/llvm-project/commit/70de9b21cbdeb1297108c4ee520b8f6dbd6496a7
DIFF: 
https://github.com/llvm/llvm-project/commit/70de9b21cbdeb1297108c4ee520b8f6dbd6496a7.diff

LOG: Revert "[lldb][DWARF] Do not complete type from declaration die. (#91799)"

This reverts commit a7eff59f78f08f8ef0487dfe2a136fb311af4fd0.

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 034817c3b4fa1..f8101aba5c627 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -2306,11 +2306,6 @@ bool DWARFASTParserClang::CompleteTypeFromDWARF(const 
DWARFDIE ,
 
   if (!die)
 return false;
-  ParsedDWARFTypeAttributes attrs(die);
-  bool is_forward_declaration = IsForwardDeclaration(
-  die, attrs, SymbolFileDWARF::GetLanguage(*die.GetCU()));
-  if (is_forward_declaration)
-return false;
 
   const dw_tag_t tag = die.Tag();
 



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 37b8e5f - Revert "[lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (#90663)"

2024-05-13 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2024-05-13T17:47:49-07:00
New Revision: 37b8e5feb1d065a7c474e6595bac6d2f65faeb51

URL: 
https://github.com/llvm/llvm-project/commit/37b8e5feb1d065a7c474e6595bac6d2f65faeb51
DIFF: 
https://github.com/llvm/llvm-project/commit/37b8e5feb1d065a7c474e6595bac6d2f65faeb51.diff

LOG: Revert "[lldb][DWARF] Delay struct/class/union definition DIE searching 
when parsing declaration DIEs. (#90663)"

This reverts commit 9a7262c2601874e5aa64c5db19746770212d4b44.

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.h
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
lldb/source/Plugins/SymbolFile/DWARF/UniqueDWARFASTType.cpp
lldb/source/Plugins/SymbolFile/DWARF/UniqueDWARFASTType.h

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.h
index e144cf0f9bd94..66db396279e06 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.h
@@ -60,8 +60,6 @@ class DWARFASTParser {
 
   virtual ConstString GetDIEClassTemplateParams(const DWARFDIE ) = 0;
 
-  virtual lldb_private::Type *FindDefinitionTypeForDIE(const DWARFDIE ) = 
0;
-
   static std::optional
   ParseChildArrayInfo(const DWARFDIE _die,
   const ExecutionContext *exe_ctx = nullptr);

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 2a46be9216121..034817c3b4fa1 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -154,26 +154,6 @@ static bool TagIsRecordType(dw_tag_t tag) {
   }
 }
 
-static bool IsForwardDeclaration(const DWARFDIE ,
- const ParsedDWARFTypeAttributes ,
- LanguageType cu_language) {
-  if (attrs.is_forward_declaration)
-return true;
-
-  // Work around an issue with clang at the moment where forward
-  // declarations for objective C classes are emitted as:
-  //  DW_TAG_structure_type [2]
-  //  DW_AT_name( "ForwardObjcClass" )
-  //  DW_AT_byte_size( 0x00 )
-  //  DW_AT_decl_file( "..." )
-  //  DW_AT_decl_line( 1 )
-  //
-  // Note that there is no DW_AT_declaration and there are no children,
-  // and the byte size is zero.
-  return attrs.byte_size && *attrs.byte_size == 0 && attrs.name &&
- !die.HasChildren() && cu_language == eLanguageTypeObjC;
-}
-
 TypeSP DWARFASTParserClang::ParseTypeFromClangModule(const SymbolContext ,
  const DWARFDIE ,
  Log *log) {
@@ -269,9 +249,11 @@ static void ForcefullyCompleteType(CompilerType type) {
 /// This function serves a similar purpose as RequireCompleteType above, but it
 /// avoids completing the type if it is not immediately necessary. It only
 /// ensures we _can_ complete the type later.
-void DWARFASTParserClang::PrepareContextToReceiveMembers(
-clang::DeclContext *decl_ctx, const DWARFDIE _ctx_die,
-const DWARFDIE , const char *type_name_cstr) {
+static void PrepareContextToReceiveMembers(TypeSystemClang ,
+   ClangASTImporter _importer,
+   clang::DeclContext *decl_ctx,
+   DWARFDIE die,
+   const char *type_name_cstr) {
   auto *tag_decl_ctx = clang::dyn_cast(decl_ctx);
   if (!tag_decl_ctx)
 return; // Non-tag context are always ready.
@@ -286,8 +268,7 @@ void DWARFASTParserClang::PrepareContextToReceiveMembers(
   // gmodules case), we can complete the type by doing a full import.
 
   // If this type was not imported from an external AST, there's nothing to do.
-  CompilerType type = m_ast.GetTypeForDecl(tag_decl_ctx);
-  ClangASTImporter _importer = GetClangASTImporter();
+  CompilerType type = ast.GetTypeForDecl(tag_decl_ctx);
   if (type && ast_importer.CanImport(type)) {
 auto qual_type = ClangUtil::GetQualType(type);
 if (ast_importer.RequireCompleteType(qual_type))
@@ -298,13 +279,6 @@ void DWARFASTParserClang::PrepareContextToReceiveMembers(
 type_name_cstr ? type_name_cstr : "", die.GetOffset());
   }
 
-  // By searching for the definition DIE of the decl_ctx type, we will either:
-  // 1. Found the the definition DIE and start its definition with
-  // TypeSystemClang::StartTagDeclarationDefinition.
-  // 2. Unable to find it, then need to forcefully complete it.
-  FindDefinitionTypeForDIE(decl_ctx_die);
-  if 

[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #91868)

2024-05-13 Thread Adrian Prantl via lldb-commits

adrian-prantl wrote:

> Re-apply https://github.com/llvm/llvm-project/pull/81196, with a fix.

It's usually helpful to indicate what/where the fix is to make it easier to 
re-review.

https://github.com/llvm/llvm-project/pull/91868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #91868)

2024-05-13 Thread Adrian Prantl via lldb-commits


@@ -658,6 +659,38 @@ static char ConvertValueObjectStyleToChar(
   return '\0';
 }
 
+static llvm::Regex LLVMFormatPattern{"x[-+]?\\d*|n|d", 
llvm::Regex::IgnoreCase};
+
+static bool DumpValueWithLLVMFormat(Stream , llvm::StringRef options,
+ValueObject ) {
+  std::string formatted;
+  std::string llvm_format = ("{0:" + options + "}").str();
+
+  // Options supported by format_provider for integral arithmetic types.
+  // See table in FormatProviders.h.
+
+  auto type_info = valobj.GetTypeInfo();
+  if (type_info & eTypeIsInteger && LLVMFormatPattern.match(options)) {

adrian-prantl wrote:

```suggestion
  if ((type_info & eTypeIsInteger) && LLVMFormatPattern.match(options)) {
```

https://github.com/llvm/llvm-project/pull/91868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #91868)

2024-05-13 Thread Adrian Prantl via lldb-commits

https://github.com/adrian-prantl edited 
https://github.com/llvm/llvm-project/pull/91868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #91868)

2024-05-13 Thread Adrian Prantl via lldb-commits

https://github.com/adrian-prantl approved this pull request.


https://github.com/llvm/llvm-project/pull/91868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits

https://github.com/royitaqi edited 
https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb/aarch64] Fix unwinding when signal interrupts a leaf function (PR #91321)

2024-05-13 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

(and it turns out the reason we don't have eh_frame is because _sigtramp on 
arm64 is written in C, and I'm not sure how I'm going to track which 
callee-saved register the argument is copied into, so this is definitely not 
something I can get fixed quickly.)

https://github.com/llvm/llvm-project/pull/91321
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #90663)

2024-05-13 Thread via lldb-commits

jimingham wrote:

I'm trying to reproduce locally as well.  It's pretty clear that this patch is 
implicated in the failure.  The first failure we saw both on the incremental 
bots and the first failure on the sanitized bots both had this patch, and no 
other really relevant ones, in the commit list.

I don't know why this is causing the failure, but it's left the bots red for 
three days now.  We really should revert this and figure out why it's failing 
before reapplying.

https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb/aarch64] Fix unwinding when signal interrupts a leaf function (PR #91321)

2024-05-13 Thread Omair Javaid via lldb-commits

omjavaid wrote:

> > LLDB became unresponsive on windows when a `thread backtrace` command was 
> > issued after hitting the exception i have temporarily reverted the change 
> > to make buildbot green.
> 
> Could you please give me some more information about the problem? I don't 
> have access to a windows arm machine, and the failure message doesn't give me 
> much to go on.

I will try to debug and get back with more information. If you need specific 
information or logs please let me know.

https://github.com/llvm/llvm-project/pull/91321
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 6cfac49 - [lldb][DWARF] Mark delayed-definition-die-searching.test unsupported on Windows

2024-05-13 Thread Muhammad Omair Javaid via lldb-commits

Author: Muhammad Omair Javaid
Date: 2024-05-14T03:58:26+05:00
New Revision: 6cfac497e96978f2bfc50a00b51c198f2ed50f82

URL: 
https://github.com/llvm/llvm-project/commit/6cfac497e96978f2bfc50a00b51c198f2ed50f82
DIFF: 
https://github.com/llvm/llvm-project/commit/6cfac497e96978f2bfc50a00b51c198f2ed50f82.diff

LOG: [lldb][DWARF] Mark delayed-definition-die-searching.test unsupported on 
Windows

This marks delayed-definition-die-searching.test as unsupported on
Windows. Clang uses link.exe as default linker if not marked explicitly
to use lld. When used with link.exe clang produces PDB format debug info
even when -gdwarf is specified.
This test will be unsupported until we make lldb-aarch64-windows buildbot
to use lld.

Added: 


Modified: 
lldb/test/Shell/SymbolFile/DWARF/delayed-definition-die-searching.test

Removed: 




diff  --git 
a/lldb/test/Shell/SymbolFile/DWARF/delayed-definition-die-searching.test 
b/lldb/test/Shell/SymbolFile/DWARF/delayed-definition-die-searching.test
index 836fcd7b587bc..d253981b498c8 100644
--- a/lldb/test/Shell/SymbolFile/DWARF/delayed-definition-die-searching.test
+++ b/lldb/test/Shell/SymbolFile/DWARF/delayed-definition-die-searching.test
@@ -1,5 +1,7 @@
 # Test definition DIE searching is delayed until complete type is required.
 
+# UNSUPPORTED: system-windows
+
 # RUN: split-file %s %t
 # RUN: %clangxx_host %t/main.cpp %t/t1_def.cpp -gdwarf -o %t.out
 # RUN: %lldb -b %t.out -s %t/lldb.cmd | FileCheck %s



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Alex Langford via lldb-commits


@@ -0,0 +1,63 @@
+//===-- SBAddressRange.h *- C++ 
-*-===//
+//
+// 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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGE_H
+#define LLDB_API_SBADDRESSRANGE_H
+
+#include "lldb/API/SBDefines.h"
+
+namespace lldb {
+
+class LLDB_API SBAddressRange {
+public:
+  SBAddressRange();
+
+  SBAddressRange(const lldb::SBAddressRange );
+
+  SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size);
+
+  ~SBAddressRange();
+
+  const lldb::SBAddressRange =(const lldb::SBAddressRange );
+
+  void Clear();
+
+  bool IsValid() const;
+
+  /// Get the base address of the range.
+  ///
+  /// \return
+  /// Base address object.
+  lldb::SBAddress GetBaseAddress() const;
+
+  /// Get the byte size of this range.
+  ///
+  /// \return
+  /// The size in bytes of this address range.
+  lldb::addr_t GetByteSize() const;
+
+protected:
+  friend class SBAddressRangeList;
+  friend class SBBlock;
+  friend class SBFunction;
+
+  lldb_private::AddressRange ();
+
+  const lldb_private::AddressRange () const;
+
+private:
+  AddressRangeUP m_opaque_up;
+};
+
+#ifndef SWIG
+bool LLDB_API operator==(const SBAddressRange , const SBAddressRange );
+#endif

bulbazord wrote:

Yes, I would strongly prefer that. Freestanding operators are powerful and 
useful, but in my experience they cause headaches when trying to use them with 
tooling. (e.g. swift/C++ interop, clang-based tooling, etc.)

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB/Coredump] Only take the Pthread from stack start to the stackpointer + red_zone (PR #92002)

2024-05-13 Thread Greg Clayton via lldb-commits


@@ -6410,12 +6410,20 @@ GetCoreFileSaveRangesStackOnly(Process ,
 if (!reg_ctx_sp)
   continue;
 const addr_t sp = reg_ctx_sp->GetSP();
+const size_t red_zone = process.GetABI()->GetRedZoneSize();
 lldb_private::MemoryRegionInfo sp_region;
 if (process.GetMemoryRegionInfo(sp, sp_region).Success()) {
   // Only add this region if not already added above. If our stack pointer
   // is pointing off in the weeds, we will want this range.
-  if (stack_bases.count(sp_region.GetRange().GetRangeBase()) == 0)
+  if (stack_bases.count(sp_region.GetRange().GetRangeBase()) == 0) {
+// Take only the start of the stack to the stack pointer and include 
the redzone.
+// Because stacks grow 'down' to include the red_zone we have to 
subtract it from the sp.
+const size_t stack_head = (sp - red_zone);
+const size_t stack_size = sp_region.GetRange().GetRangeEnd() - 
(stack_head);

clayborg wrote:

remove `()` around `stack_head`

https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB/Coredump] Only take the Pthread from stack start to the stackpointer + red_zone (PR #92002)

2024-05-13 Thread Greg Clayton via lldb-commits

https://github.com/clayborg requested changes to this pull request.

Change look good for the `GetCoreFileSaveRangesStackOnly`, but we want this to 
work for the other two modes `modified-memory` and `full`. So we need to fix 
`GetCoreFileSaveRangesFull` and `GetCoreFileSaveRangesDirtyOnly`. 

https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB/Coredump] Only take the Pthread from stack start to the stackpointer + red_zone (PR #92002)

2024-05-13 Thread Greg Clayton via lldb-commits

https://github.com/clayborg edited 
https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,63 @@
+//===-- SBAddressRange.h *- C++ 
-*-===//
+//
+// 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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGE_H
+#define LLDB_API_SBADDRESSRANGE_H
+
+#include "lldb/API/SBDefines.h"
+
+namespace lldb {
+
+class LLDB_API SBAddressRange {
+public:
+  SBAddressRange();
+
+  SBAddressRange(const lldb::SBAddressRange );
+
+  SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size);
+
+  ~SBAddressRange();
+
+  const lldb::SBAddressRange =(const lldb::SBAddressRange );
+
+  void Clear();
+
+  bool IsValid() const;
+
+  /// Get the base address of the range.
+  ///
+  /// \return
+  /// Base address object.
+  lldb::SBAddress GetBaseAddress() const;
+
+  /// Get the byte size of this range.
+  ///
+  /// \return
+  /// The size in bytes of this address range.
+  lldb::addr_t GetByteSize() const;
+
+protected:
+  friend class SBAddressRangeList;
+  friend class SBBlock;
+  friend class SBFunction;
+
+  lldb_private::AddressRange ();
+
+  const lldb_private::AddressRange () const;
+
+private:
+  AddressRangeUP m_opaque_up;
+};
+
+#ifndef SWIG
+bool LLDB_API operator==(const SBAddressRange , const SBAddressRange );
+#endif

clayborg wrote:

@bulbazord: so you want him to just add a `operator==` as a method?

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,63 @@
+//===-- SBAddressRange.h *- C++ 
-*-===//
+//
+// 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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGE_H
+#define LLDB_API_SBADDRESSRANGE_H
+
+#include "lldb/API/SBDefines.h"
+
+namespace lldb {
+
+class LLDB_API SBAddressRange {
+public:
+  SBAddressRange();
+
+  SBAddressRange(const lldb::SBAddressRange );
+
+  SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size);

clayborg wrote:

If you actually want to resolve a `file_addr` then you must supply a 
`lldb::SBModule` which can be used to resolve it:
```
SBAddressRange(lldb::addr_t file_addr, ldb::SBModule module, lldb::addr_t 
byte_size);
``` 
That being said, I don't know if we want this constructor. We probably want:
```
SBAddressRange(SBAddress base_addr, lldb::addr_t byte_size);
```
You might want this API because you want to just make a list of load address 
ranges. I would suggest that you would use either of these `SBAddress` 
constructors:
```
  SBAddress(lldb::SBSection section, lldb::addr_t offset);
  SBAddress(lldb::addr_t load_addr, lldb::SBTarget );
```
So if you want to make a `SBAddress` using a "load_addr", you would do:
```
SBAddress(load_addr, target);
```
If `load_addr` resolved to a section that is loaded, then the resulting 
`SBAddress` will contain a valid section. If the `load_addr` is somewhere in 
the process, but not in a section the resulting `SBAddress` will have no 
section and the offset will be set to `load_addr`

So change this to be:
```
SBAddressRange(SBAddress base_addr, lldb::addr_t byte_size);
```


https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,3 @@
+#include 
+
+int main() { std::cout << "Hello World!" << std::endl; }

clayborg wrote:

No need to use  here right? I would just do a simpler `main`:
```
int main() {
  return 0;
}
```
(remove `#include` and use of `std::cout`). This will reduce the size and speed 
up compilation.

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,130 @@
+
+//===-- SBAddressRangeList.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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRangeList.h"
+#include "Utils.h"
+#include "lldb/API/SBAddressRange.h"
+#include "lldb/Core/AddressRange.h"
+#include "lldb/Utility/Instrumentation.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+class AddressRangeListImpl {
+public:
+  AddressRangeListImpl() : m_ranges() {}
+
+  AddressRangeListImpl(const AddressRangeListImpl ) = default;
+
+  AddressRangeListImpl =(const AddressRangeListImpl ) {
+if (this == )
+  return *this;
+m_ranges = rhs.m_ranges;
+return *this;
+  }
+
+  size_t GetSize() const { return m_ranges.size(); }
+
+  void Reserve(size_t capacity) { return m_ranges.reserve(capacity); }
+
+  void Append(const AddressRange _region) {
+m_ranges.emplace_back(sb_region);
+  }
+
+  void Append(const AddressRangeListImpl ) {
+Reserve(GetSize() + list.GetSize());
+
+for (const auto  : list.m_ranges)
+  Append(range);
+  }
+
+  void Clear() { m_ranges.clear(); }
+
+  bool GetAddressRangeAtIndex(size_t index, AddressRange _range) {
+if (index >= GetSize())
+  return false;
+addr_range = m_ranges[index];
+return true;
+  }
+
+  AddressRanges () { return m_ranges; }
+
+  const AddressRanges () const { return m_ranges; }
+
+private:
+  AddressRanges m_ranges;
+};
+
+AddressRanges ::ref() { return m_opaque_up->Ref(); }
+
+const AddressRanges ::ref() const {
+  return m_opaque_up->Ref();
+}
+
+SBAddressRangeList::SBAddressRangeList()
+: m_opaque_up(new AddressRangeListImpl()) {
+  LLDB_INSTRUMENT_VA(this);
+}
+
+SBAddressRangeList::SBAddressRangeList(const SBAddressRangeList )
+: m_opaque_up(new AddressRangeListImpl(*rhs.m_opaque_up)) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+}
+
+SBAddressRangeList::~SBAddressRangeList() = default;
+
+const SBAddressRangeList &
+SBAddressRangeList::operator=(const SBAddressRangeList ) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  if (this != ) {
+*m_opaque_up = *rhs.m_opaque_up;
+  }

clayborg wrote:

remove `{}` per llvm coding guidelines for single statement `if`

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Greg Clayton via lldb-commits


@@ -219,6 +219,16 @@ lldb::SBAddress SBBlock::GetRangeEndAddress(uint32_t idx) {
   return sb_addr;
 }
 
+lldb::SBAddressRange SBBlock::GetRangeAtIndex(uint32_t idx) {
+  LLDB_INSTRUMENT_VA(this, idx);
+
+  lldb::SBAddressRange sb_range;
+  if (m_opaque_ptr) {
+m_opaque_ptr->GetRangeAtIndex(idx, sb_range.ref());
+  }

clayborg wrote:

remove `{}` per coding guidelines

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,58 @@
+//===-- SBAddressRangeList.h *- C++ 
-*-===//
+//
+// 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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGELIST_H
+#define LLDB_API_SBADDRESSRANGELIST_H
+
+#include 
+
+#include "lldb/API/SBDefines.h"
+
+class AddressRangeListImpl;
+
+namespace lldb {
+
+class LLDB_API SBAddressRangeList {
+public:
+  SBAddressRangeList();
+
+  SBAddressRangeList(const lldb::SBAddressRangeList );
+
+  ~SBAddressRangeList();
+
+  const lldb::SBAddressRangeList &
+  operator=(const lldb::SBAddressRangeList );
+
+  uint32_t GetSize() const;
+
+  void Clear();
+
+  bool GetAddressRangeAtIndex(uint64_t idx, SBAddressRange _range);
+
+  void Append(const lldb::SBAddressRange _range);
+
+  void Append(const lldb::SBAddressRangeList _range_list);
+
+protected:
+  const AddressRangeListImpl *operator->() const;
+
+  const AddressRangeListImpl *() const;
+
+private:
+  friend class SBProcess;
+
+  lldb_private::AddressRanges ();
+
+  const lldb_private::AddressRanges () const;

clayborg wrote:

yes, please expose the type in the `std::unique_ptr` which is 
`AddressRangeListImpl`

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,78 @@
+//===-- SBAddressRange.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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRange.h"
+#include "Utils.h"
+#include "lldb/API/SBAddress.h"
+#include "lldb/Core/AddressRange.h"
+#include "lldb/Utility/Instrumentation.h"
+#include 
+#include 
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBAddressRange::SBAddressRange()
+: m_opaque_up(std::make_unique()) {
+  LLDB_INSTRUMENT_VA(this);
+}
+
+SBAddressRange::SBAddressRange(const SBAddressRange ) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  m_opaque_up = clone(rhs.m_opaque_up);
+}
+
+SBAddressRange::SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size)
+: m_opaque_up(std::make_unique(file_addr, byte_size)) {
+  LLDB_INSTRUMENT_VA(this, file_addr, byte_size);
+}
+
+SBAddressRange::~SBAddressRange() = default;
+
+const SBAddressRange ::operator=(const SBAddressRange ) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  if (this != )
+m_opaque_up = clone(rhs.m_opaque_up);
+  return *this;
+}
+
+void SBAddressRange::Clear() {
+  LLDB_INSTRUMENT_VA(this);
+
+  m_opaque_up.reset();
+}
+
+bool SBAddressRange::IsValid() const {
+  return m_opaque_up && m_opaque_up->IsValid();
+}
+
+lldb::SBAddress SBAddressRange::GetBaseAddress() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  assert(m_opaque_up.get() && "AddressRange is NULL");
+  return lldb::SBAddress(m_opaque_up->GetBaseAddress());
+}
+
+lldb::addr_t SBAddressRange::GetByteSize() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  assert(m_opaque_up.get() && "AddressRange is NULL");
+  return m_opaque_up->GetByteSize();

clayborg wrote:

No asserts, do the right thing:
```
if (IsValid())
  return m_opaque_up->GetByteSize();
return 0;
```

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,78 @@
+//===-- SBAddressRange.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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRange.h"
+#include "Utils.h"
+#include "lldb/API/SBAddress.h"
+#include "lldb/Core/AddressRange.h"
+#include "lldb/Utility/Instrumentation.h"
+#include 
+#include 
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBAddressRange::SBAddressRange()
+: m_opaque_up(std::make_unique()) {
+  LLDB_INSTRUMENT_VA(this);
+}
+
+SBAddressRange::SBAddressRange(const SBAddressRange ) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  m_opaque_up = clone(rhs.m_opaque_up);
+}
+
+SBAddressRange::SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size)
+: m_opaque_up(std::make_unique(file_addr, byte_size)) {
+  LLDB_INSTRUMENT_VA(this, file_addr, byte_size);
+}
+
+SBAddressRange::~SBAddressRange() = default;
+
+const SBAddressRange ::operator=(const SBAddressRange ) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  if (this != )
+m_opaque_up = clone(rhs.m_opaque_up);
+  return *this;
+}
+
+void SBAddressRange::Clear() {
+  LLDB_INSTRUMENT_VA(this);
+
+  m_opaque_up.reset();
+}
+
+bool SBAddressRange::IsValid() const {
+  return m_opaque_up && m_opaque_up->IsValid();
+}
+
+lldb::SBAddress SBAddressRange::GetBaseAddress() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  assert(m_opaque_up.get() && "AddressRange is NULL");

clayborg wrote:

No assert here and return a default constructed `SBAddress` if not valid:
```
if (IsValid())
  return lldb::SBAddress(m_opaque_up->GetBaseAddress());
return lldb::SBAddress();
```

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Greg Clayton via lldb-commits


@@ -52,6 +53,8 @@ class LLDB_API SBBlock {
 
   lldb::SBAddress GetRangeEndAddress(uint32_t idx);
 
+  lldb::SBAddressRange GetRangeAtIndex(uint32_t idx);
+

clayborg wrote:

Use `SBAddressRangeList` here:
```
SBAddressRangeList GetRanges();
```


https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,78 @@
+//===-- SBAddressRange.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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRange.h"
+#include "Utils.h"
+#include "lldb/API/SBAddress.h"
+#include "lldb/Core/AddressRange.h"
+#include "lldb/Utility/Instrumentation.h"
+#include 
+#include 
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBAddressRange::SBAddressRange()
+: m_opaque_up(std::make_unique()) {
+  LLDB_INSTRUMENT_VA(this);
+}
+
+SBAddressRange::SBAddressRange(const SBAddressRange ) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  m_opaque_up = clone(rhs.m_opaque_up);
+}
+
+SBAddressRange::SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size)
+: m_opaque_up(std::make_unique(file_addr, byte_size)) {
+  LLDB_INSTRUMENT_VA(this, file_addr, byte_size);
+}
+
+SBAddressRange::~SBAddressRange() = default;
+
+const SBAddressRange ::operator=(const SBAddressRange ) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  if (this != )
+m_opaque_up = clone(rhs.m_opaque_up);
+  return *this;
+}
+
+void SBAddressRange::Clear() {
+  LLDB_INSTRUMENT_VA(this);
+
+  m_opaque_up.reset();
+}
+
+bool SBAddressRange::IsValid() const {
+  return m_opaque_up && m_opaque_up->IsValid();
+}
+
+lldb::SBAddress SBAddressRange::GetBaseAddress() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  assert(m_opaque_up.get() && "AddressRange is NULL");
+  return lldb::SBAddress(m_opaque_up->GetBaseAddress());
+}
+
+lldb::addr_t SBAddressRange::GetByteSize() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  assert(m_opaque_up.get() && "AddressRange is NULL");
+  return m_opaque_up->GetByteSize();
+}
+
+AddressRange ::ref() {
+  assert(m_opaque_up.get() && "AddressRange is NULL");
+  return *m_opaque_up;
+}
+
+const AddressRange ::ref() const {
+  assert(m_opaque_up.get() && "AddressRange is NULL");
+  return *m_opaque_up;
+}

clayborg wrote:

asserts are ok here as users are expected to check first. Are we using these 
functions? `const` does mean anything in classes that have a single 
`std::shared_ptr<>` or `std::unique_ptr<>`, so no need for this. This is 
because `const` just means that we don't allow the shared or unique pointer to 
change, it doesn't enforce anything. This also means we don't need to make 
methods that take `const SBAddressRange`, we just use a non-const version.

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,58 @@
+//===-- SBAddressRangeList.h *- C++ 
-*-===//
+//
+// 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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGELIST_H
+#define LLDB_API_SBADDRESSRANGELIST_H
+
+#include 
+
+#include "lldb/API/SBDefines.h"
+
+class AddressRangeListImpl;
+
+namespace lldb {
+
+class LLDB_API SBAddressRangeList {
+public:
+  SBAddressRangeList();
+
+  SBAddressRangeList(const lldb::SBAddressRangeList );
+
+  ~SBAddressRangeList();
+
+  const lldb::SBAddressRangeList &
+  operator=(const lldb::SBAddressRangeList );
+
+  uint32_t GetSize() const;
+
+  void Clear();
+
+  bool GetAddressRangeAtIndex(uint64_t idx, SBAddressRange _range);

clayborg wrote:

yes, please make this:
```
SBAddressRange GetAddressRangeAtIndex(uint64_t idx);
```
Easier to use in code and in python. Return a default constructed 
`SBAddressRange` if `idx` is out of range. 

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,63 @@
+//===-- SBAddressRange.h *- C++ 
-*-===//
+//
+// 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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGE_H
+#define LLDB_API_SBADDRESSRANGE_H
+
+#include "lldb/API/SBDefines.h"
+
+namespace lldb {
+
+class LLDB_API SBAddressRange {
+public:
+  SBAddressRange();
+
+  SBAddressRange(const lldb::SBAddressRange );
+
+  SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size);
+
+  ~SBAddressRange();
+
+  const lldb::SBAddressRange =(const lldb::SBAddressRange );
+
+  void Clear();
+
+  bool IsValid() const;

clayborg wrote:

Please add header doc on what will make a `SBAddressRange` valid. Something 
like:
```
Check the address range refers to a valid base address and has a byte size 
greater than zero.
```

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Greg Clayton via lldb-commits

https://github.com/clayborg edited 
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Greg Clayton via lldb-commits

https://github.com/clayborg requested changes to this pull request.


https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb/aarch64] Fix unwinding when signal interrupts a leaf function (PR #91321)

2024-05-13 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

Ah, so the problem here is that we're missing the eh_frame instructions for 
_sigtramp on arm64 with macOS 14.  `signal_generating_add` is a frameless 
function (a great stress test in this instance), and _sigtramp is called with 
enough of a faked-up stack that a stack walk will find the last frame that set 
up a stack frame before faulting, main in this case.  But we skip 
`signal_generating_add`.  We're going to need to skip this test on macOS for 
now, and I'll dig in to where the eh_frame instructions went and see about 
getting them re-added, but it may take a while to get that into builds and on 
to the bots.

https://github.com/llvm/llvm-project/pull/91321
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)

2024-05-13 Thread via lldb-commits

https://github.com/royitaqi updated 
https://github.com/llvm/llvm-project/pull/90703

>From 0fd67e2de7e702ce6f7353845454ea7ff9f980d6 Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Tue, 30 Apr 2024 21:35:49 -0700
Subject: [PATCH 01/14] Add SBCommandInterpreter::GetTranscript()

---
 lldb/include/lldb/API/SBCommandInterpreter.h | 12 +---
 lldb/source/API/SBCommandInterpreter.cpp |  7 ++-
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/lldb/include/lldb/API/SBCommandInterpreter.h 
b/lldb/include/lldb/API/SBCommandInterpreter.h
index ba2e049204b8e..d65f06d676f91 100644
--- a/lldb/include/lldb/API/SBCommandInterpreter.h
+++ b/lldb/include/lldb/API/SBCommandInterpreter.h
@@ -247,13 +247,13 @@ class SBCommandInterpreter {
lldb::SBStringList ,
lldb::SBStringList );
 
-  /// Returns whether an interrupt flag was raised either by the SBDebugger - 
+  /// Returns whether an interrupt flag was raised either by the SBDebugger -
   /// when the function is not running on the RunCommandInterpreter thread, or
   /// by SBCommandInterpreter::InterruptCommand if it is.  If your code is 
doing
-  /// interruptible work, check this API periodically, and interrupt if it 
+  /// interruptible work, check this API periodically, and interrupt if it
   /// returns true.
   bool WasInterrupted() const;
-  
+
   /// Interrupts the command currently executing in the RunCommandInterpreter
   /// thread.
   ///
@@ -318,6 +318,12 @@ class SBCommandInterpreter {
 
   SBStructuredData GetStatistics();
 
+  /// Returns a list of handled commands, output and error. Each element in
+  /// the list is a dictionary with three keys: "command" (string), "output"
+  /// (list of strings) and optionally "error" (list of strings). Each string
+  /// in "output" and "error" is a line (without EOL characteres).
+  SBStructuredData GetTranscript();
+
 protected:
   friend class lldb_private::CommandPluginInterfaceImplementation;
 
diff --git a/lldb/source/API/SBCommandInterpreter.cpp 
b/lldb/source/API/SBCommandInterpreter.cpp
index 83c0951c56db6..242b3f8f09c48 100644
--- a/lldb/source/API/SBCommandInterpreter.cpp
+++ b/lldb/source/API/SBCommandInterpreter.cpp
@@ -150,7 +150,7 @@ bool SBCommandInterpreter::WasInterrupted() const {
 
 bool SBCommandInterpreter::InterruptCommand() {
   LLDB_INSTRUMENT_VA(this);
-  
+
   return (IsValid() ? m_opaque_ptr->InterruptCommand() : false);
 }
 
@@ -571,6 +571,11 @@ SBStructuredData SBCommandInterpreter::GetStatistics() {
   return data;
 }
 
+SBStructuredData SBCommandInterpreter::GetTranscript() {
+  LLDB_INSTRUMENT_VA(this);
+  return SBStructuredData();
+}
+
 lldb::SBCommand SBCommandInterpreter::AddMultiwordCommand(const char *name,
   const char *help) {
   LLDB_INSTRUMENT_VA(this, name, help);

>From a1c948ceabaccdc3407e0c4eae0ebc594a9b68b7 Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Wed, 1 May 2024 13:45:47 -0700
Subject: [PATCH 02/14] Implement the new API

---
 .../lldb/Interpreter/CommandInterpreter.h | 12 +--
 lldb/include/lldb/Utility/StructuredData.h| 11 +++---
 lldb/source/API/SBCommandInterpreter.cpp  |  8 -
 .../source/Interpreter/CommandInterpreter.cpp | 21 ++-
 lldb/source/Utility/StructuredData.cpp| 35 +++
 5 files changed, 79 insertions(+), 8 deletions(-)

diff --git a/lldb/include/lldb/Interpreter/CommandInterpreter.h 
b/lldb/include/lldb/Interpreter/CommandInterpreter.h
index 70a55a77465bf..9474c41c0dced 100644
--- a/lldb/include/lldb/Interpreter/CommandInterpreter.h
+++ b/lldb/include/lldb/Interpreter/CommandInterpreter.h
@@ -22,6 +22,7 @@
 #include "lldb/Utility/Log.h"
 #include "lldb/Utility/StreamString.h"
 #include "lldb/Utility/StringList.h"
+#include "lldb/Utility/StructuredData.h"
 #include "lldb/lldb-forward.h"
 #include "lldb/lldb-private.h"
 
@@ -241,7 +242,7 @@ class CommandInterpreter : public Broadcaster,
 eCommandTypesAllThem = 0x  //< all commands
   };
 
-  // The CommandAlias and CommandInterpreter both have a hand in 
+  // The CommandAlias and CommandInterpreter both have a hand in
   // substituting for alias commands.  They work by writing special tokens
   // in the template form of the Alias command, and then detecting them when 
the
   // command is executed.  These are the special tokens:
@@ -576,7 +577,7 @@ class CommandInterpreter : public Broadcaster,
   void SetEchoCommentCommands(bool enable);
 
   bool GetRepeatPreviousCommand() const;
-  
+
   bool GetRequireCommandOverwrite() const;
 
   const CommandObject::CommandMap () const {
@@ -647,6 +648,7 @@ class CommandInterpreter : public Broadcaster,
   }
 
   llvm::json::Value GetStatistics();
+  StructuredData::ArraySP GetTranscript() const;
 
 protected:
   friend class Debugger;
@@ -766,6 +768,12 @@ class CommandInterpreter : public Broadcaster,
   CommandUsageMap 

[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits


@@ -1689,35 +1689,56 @@ void 
SBDebugger::SetLoggingCallback(lldb::LogOutputCallback log_callback,
 void SBDebugger::SetDestroyCallback(
 lldb::SBDebuggerDestroyCallback destroy_callback, void *baton) {
   LLDB_INSTRUMENT_VA(this, destroy_callback, baton);
+
   if (m_opaque_sp) {
-return m_opaque_sp->SetDestroyCallback(
-destroy_callback, baton);
+m_opaque_sp->SetDestroyCallback(destroy_callback, baton);
   }
 }
 
+lldb::destroy_callback_token_t
+SBDebugger::AddDestroyCallback(lldb::SBDebuggerDestroyCallback 
destroy_callback,
+   void *baton) {
+  LLDB_INSTRUMENT_VA(this, destroy_callback, baton);
+
+  if (m_opaque_sp) {
+return m_opaque_sp->AddDestroyCallback(destroy_callback, baton);
+  }
+  return LLDB_INVALID_DESTROY_CALLBACK_TOKEN;
+}
+
+bool SBDebugger::RemoveDestroyCallback(lldb::destroy_callback_token_t token) {
+  LLDB_INSTRUMENT_VA(this, token);
+
+  if (m_opaque_sp) {
+return m_opaque_sp->RemoveDestroyCallback(token);
+  }
+  return false;
+}
+
 SBTrace
 SBDebugger::LoadTraceFromFile(SBError ,
   const SBFileSpec _description_file) {
   LLDB_INSTRUMENT_VA(this, error, trace_description_file);
+
   return SBTrace::LoadTraceFromFile(error, *this, trace_description_file);
 }
 
 void SBDebugger::RequestInterrupt() {
   LLDB_INSTRUMENT_VA(this);
-  
+
   if (m_opaque_sp)
-m_opaque_sp->RequestInterrupt();  
+m_opaque_sp->RequestInterrupt();
 }
 void SBDebugger::CancelInterruptRequest()  {
   LLDB_INSTRUMENT_VA(this);
-  
+
   if (m_opaque_sp)
-m_opaque_sp->CancelInterruptRequest();  
+m_opaque_sp->CancelInterruptRequest();
 }
 
 bool SBDebugger::InterruptRequested()   {
   LLDB_INSTRUMENT_VA(this);
-  
+
   if (m_opaque_sp)

royitaqi wrote:

Manually added them back, because `git clang-format` isn't clever enough to 
ignore the lines which I didn't modify.

https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits

https://github.com/royitaqi updated 
https://github.com/llvm/llvm-project/pull/89868

>From 079a550481d4cdcb69ad01c376b5e1f0632a07d6 Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Tue, 23 Apr 2024 18:10:21 -0700
Subject: [PATCH 01/16] Allow multiple destroy callbacks in
 `SBDebugger::SetDestroyCallback()`

---
 lldb/include/lldb/Core/Debugger.h |  4 ++--
 lldb/source/Core/Debugger.cpp | 10 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index 418c2403d020f..20884f954ec7d 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -731,8 +731,8 @@ class Debugger : public 
std::enable_shared_from_this,
   lldb::TargetSP m_dummy_target_sp;
   Diagnostics::CallbackID m_diagnostics_callback_id;
 
-  lldb_private::DebuggerDestroyCallback m_destroy_callback = nullptr;
-  void *m_destroy_callback_baton = nullptr;
+  std::vector>
+   m_destroy_callback_and_baton;
 
   uint32_t m_interrupt_requested = 0; ///< Tracks interrupt requests
   std::mutex m_interrupt_mutex;
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 19b3cf3bbf46b..0ebdf2b0a0f97 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -743,10 +743,11 @@ DebuggerSP 
Debugger::CreateInstance(lldb::LogOutputCallback log_callback,
 }
 
 void Debugger::HandleDestroyCallback() {
-  if (m_destroy_callback) {
-m_destroy_callback(GetID(), m_destroy_callback_baton);
-m_destroy_callback = nullptr;
+  const lldb::user_id_t user_id = GetID();
+  for (const auto _and_baton : m_destroy_callback_and_baton) {
+callback_and_baton.first(user_id, callback_and_baton.second);
   }
+  m_destroy_callback_and_baton.clear();
 }
 
 void Debugger::Destroy(DebuggerSP _sp) {
@@ -1427,8 +1428,7 @@ void Debugger::SetLoggingCallback(lldb::LogOutputCallback 
log_callback,
 
 void Debugger::SetDestroyCallback(
 lldb_private::DebuggerDestroyCallback destroy_callback, void *baton) {
-  m_destroy_callback = destroy_callback;
-  m_destroy_callback_baton = baton;
+  m_destroy_callback_and_baton.emplace_back(destroy_callback, baton);
 }
 
 static void PrivateReportProgress(Debugger , uint64_t progress_id,

>From 771b52723be8d0ffecaf8f0818105cfdb82ba332 Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Tue, 23 Apr 2024 21:05:58 -0700
Subject: [PATCH 02/16] Fix code format

---
 lldb/include/lldb/Core/Debugger.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index 20884f954ec7d..af025219b0bc1 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -732,7 +732,7 @@ class Debugger : public 
std::enable_shared_from_this,
   Diagnostics::CallbackID m_diagnostics_callback_id;
 
   std::vector>
-   m_destroy_callback_and_baton;
+  m_destroy_callback_and_baton;
 
   uint32_t m_interrupt_requested = 0; ///< Tracks interrupt requests
   std::mutex m_interrupt_mutex;

>From d1f13cad8a3789a994572459893b32a225ba3e1b Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Wed, 24 Apr 2024 11:55:16 -0700
Subject: [PATCH 03/16] Add `AddDestroyCallback()` and `ClearDestroyCallback()`

---
 lldb/include/lldb/Core/Debugger.h | 11 +++
 lldb/source/Core/Debugger.cpp | 12 +++-
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index af025219b0bc1..5b3e433f09c68 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -568,10 +568,21 @@ class Debugger : public 
std::enable_shared_from_this,
 
   static void ReportSymbolChange(const ModuleSpec _spec);
 
+  /// Add a callback for when the debugger is destroyed. A list is maintained
+  /// internally.
+  void
+  AddDestroyCallback(lldb_private::DebuggerDestroyCallback destroy_callback,
+ void *baton);
+
+  /// Clear the list of callbacks, then add the callback.
   void
   SetDestroyCallback(lldb_private::DebuggerDestroyCallback destroy_callback,
  void *baton);
 
+  /// Clear the list of callbacks.
+  void
+  ClearDestroyCallback();
+
   /// Manually start the global event handler thread. It is useful to plugins
   /// that directly use the \a lldb_private namespace and want to use the
   /// debugger's default event handler thread instead of defining their own.
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 0ebdf2b0a0f97..159913642f253 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -1426,11 +1426,21 @@ void 
Debugger::SetLoggingCallback(lldb::LogOutputCallback log_callback,
   std::make_shared(log_callback, baton);
 }
 
-void Debugger::SetDestroyCallback(
+void Debugger::AddDestroyCallback(
 lldb_private::DebuggerDestroyCallback destroy_callback, void *baton) {
   

[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits

https://github.com/royitaqi updated 
https://github.com/llvm/llvm-project/pull/89868

>From 079a550481d4cdcb69ad01c376b5e1f0632a07d6 Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Tue, 23 Apr 2024 18:10:21 -0700
Subject: [PATCH 01/15] Allow multiple destroy callbacks in
 `SBDebugger::SetDestroyCallback()`

---
 lldb/include/lldb/Core/Debugger.h |  4 ++--
 lldb/source/Core/Debugger.cpp | 10 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index 418c2403d020f..20884f954ec7d 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -731,8 +731,8 @@ class Debugger : public 
std::enable_shared_from_this,
   lldb::TargetSP m_dummy_target_sp;
   Diagnostics::CallbackID m_diagnostics_callback_id;
 
-  lldb_private::DebuggerDestroyCallback m_destroy_callback = nullptr;
-  void *m_destroy_callback_baton = nullptr;
+  std::vector>
+   m_destroy_callback_and_baton;
 
   uint32_t m_interrupt_requested = 0; ///< Tracks interrupt requests
   std::mutex m_interrupt_mutex;
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 19b3cf3bbf46b..0ebdf2b0a0f97 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -743,10 +743,11 @@ DebuggerSP 
Debugger::CreateInstance(lldb::LogOutputCallback log_callback,
 }
 
 void Debugger::HandleDestroyCallback() {
-  if (m_destroy_callback) {
-m_destroy_callback(GetID(), m_destroy_callback_baton);
-m_destroy_callback = nullptr;
+  const lldb::user_id_t user_id = GetID();
+  for (const auto _and_baton : m_destroy_callback_and_baton) {
+callback_and_baton.first(user_id, callback_and_baton.second);
   }
+  m_destroy_callback_and_baton.clear();
 }
 
 void Debugger::Destroy(DebuggerSP _sp) {
@@ -1427,8 +1428,7 @@ void Debugger::SetLoggingCallback(lldb::LogOutputCallback 
log_callback,
 
 void Debugger::SetDestroyCallback(
 lldb_private::DebuggerDestroyCallback destroy_callback, void *baton) {
-  m_destroy_callback = destroy_callback;
-  m_destroy_callback_baton = baton;
+  m_destroy_callback_and_baton.emplace_back(destroy_callback, baton);
 }
 
 static void PrivateReportProgress(Debugger , uint64_t progress_id,

>From 771b52723be8d0ffecaf8f0818105cfdb82ba332 Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Tue, 23 Apr 2024 21:05:58 -0700
Subject: [PATCH 02/15] Fix code format

---
 lldb/include/lldb/Core/Debugger.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index 20884f954ec7d..af025219b0bc1 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -732,7 +732,7 @@ class Debugger : public 
std::enable_shared_from_this,
   Diagnostics::CallbackID m_diagnostics_callback_id;
 
   std::vector>
-   m_destroy_callback_and_baton;
+  m_destroy_callback_and_baton;
 
   uint32_t m_interrupt_requested = 0; ///< Tracks interrupt requests
   std::mutex m_interrupt_mutex;

>From d1f13cad8a3789a994572459893b32a225ba3e1b Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Wed, 24 Apr 2024 11:55:16 -0700
Subject: [PATCH 03/15] Add `AddDestroyCallback()` and `ClearDestroyCallback()`

---
 lldb/include/lldb/Core/Debugger.h | 11 +++
 lldb/source/Core/Debugger.cpp | 12 +++-
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index af025219b0bc1..5b3e433f09c68 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -568,10 +568,21 @@ class Debugger : public 
std::enable_shared_from_this,
 
   static void ReportSymbolChange(const ModuleSpec _spec);
 
+  /// Add a callback for when the debugger is destroyed. A list is maintained
+  /// internally.
+  void
+  AddDestroyCallback(lldb_private::DebuggerDestroyCallback destroy_callback,
+ void *baton);
+
+  /// Clear the list of callbacks, then add the callback.
   void
   SetDestroyCallback(lldb_private::DebuggerDestroyCallback destroy_callback,
  void *baton);
 
+  /// Clear the list of callbacks.
+  void
+  ClearDestroyCallback();
+
   /// Manually start the global event handler thread. It is useful to plugins
   /// that directly use the \a lldb_private namespace and want to use the
   /// debugger's default event handler thread instead of defining their own.
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 0ebdf2b0a0f97..159913642f253 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -1426,11 +1426,21 @@ void 
Debugger::SetLoggingCallback(lldb::LogOutputCallback log_callback,
   std::make_shared(log_callback, baton);
 }
 
-void Debugger::SetDestroyCallback(
+void Debugger::AddDestroyCallback(
 lldb_private::DebuggerDestroyCallback destroy_callback, void *baton) {
   

[Lldb-commits] [lldb] [lldb][Windows] Enforce exec permission using Platform::Install() from Windows host (PR #91887)

2024-05-13 Thread Dmitry Vasilyev via lldb-commits

slydiman wrote:

@labath, Sorry for not being clear with my comment. Let me re-phrase.

I think unconditionally setting the executable flag for everything installed by 
Platform::Install by default for all platforms is overkill.

BTW, there is no API to change this behavior, so `by default` means always.

Implementation details aside. Test files have the correct permissions set if 
the host allows it. Platform::Install copies the host file permissions to the 
target. This seems a correct behavior except for the case when the host has a 
smaller set of permissions than the target,  or permission sets on the host and 
the target do not match significantly. I'm aware of the only such case: Windows 
host and POSIX target. Do you know more?

https://github.com/llvm/llvm-project/pull/91887
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Alex Langford via lldb-commits

bulbazord wrote:

I forgot to ask, what is the motivation behind this change? Is there something 
you can't do with the SBAPI right now or that is better expressed with 
SBAddressRange and SBAddressRangeList?

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Alex Langford via lldb-commits


@@ -0,0 +1,130 @@
+

bulbazord wrote:

remove stray line

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Alex Langford via lldb-commits


@@ -0,0 +1,130 @@
+
+//===-- SBAddressRangeList.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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRangeList.h"
+#include "Utils.h"
+#include "lldb/API/SBAddressRange.h"
+#include "lldb/Core/AddressRange.h"
+#include "lldb/Utility/Instrumentation.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+class AddressRangeListImpl {
+public:
+  AddressRangeListImpl() : m_ranges() {}
+
+  AddressRangeListImpl(const AddressRangeListImpl ) = default;
+
+  AddressRangeListImpl =(const AddressRangeListImpl ) {
+if (this == )
+  return *this;
+m_ranges = rhs.m_ranges;
+return *this;
+  }
+
+  size_t GetSize() const { return m_ranges.size(); }
+
+  void Reserve(size_t capacity) { return m_ranges.reserve(capacity); }

bulbazord wrote:

no need for return on this line, returns void.

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Alex Langford via lldb-commits


@@ -0,0 +1,63 @@
+//===-- SBAddressRange.h *- C++ 
-*-===//
+//
+// 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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGE_H
+#define LLDB_API_SBADDRESSRANGE_H
+
+#include "lldb/API/SBDefines.h"
+
+namespace lldb {
+
+class LLDB_API SBAddressRange {
+public:
+  SBAddressRange();
+
+  SBAddressRange(const lldb::SBAddressRange );
+
+  SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size);

bulbazord wrote:

`file_addr` seems like it may be a bit misleading. It might not be an address 
in a file. Maybe `base_addr`?

Why is `byte_size` an `addr_t` instead of, say, a `size_t` or `uint64_t`?

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Alex Langford via lldb-commits


@@ -0,0 +1,124 @@
+"""
+Test SBAddressRange APIs.
+"""
+
+import lldb
+from lldbsuite.test.lldbtest import *
+
+
+class AddressRangeTestCase(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
+def test_address_range_default(self):
+"""Testing default constructor."""
+empty_range = lldb.SBAddressRange()
+self.assertEqual(empty_range.IsValid(), False)
+
+def test_address_range_construction(self):
+"""Make sure the construction and getters work."""
+range = lldb.SBAddressRange(0x0400, 8)
+self.assertEqual(range.IsValid(), True)
+self.assertEqual(range.GetBaseAddress().GetOffset(), 0x0400)
+self.assertEqual(range.GetByteSize(), 8)
+
+def test_address_range_clear(self):
+"""Make sure the clear method works."""
+range = lldb.SBAddressRange(0x0400, 8)
+self.assertEqual(range.IsValid(), True)
+self.assertEqual(range.GetBaseAddress().GetOffset(), 0x0400)
+self.assertEqual(range.GetByteSize(), 8)
+
+range.Clear()
+self.assertEqual(range.IsValid(), False)
+
+def test_function(self):
+"""Make sure the range works in SBFunction APIs."""
+self.build()
+exe = self.getBuildArtifact("a.out")
+
+# Create a target by the debugger.
+target = self.dbg.CreateTarget(exe)
+self.assertTrue(target, VALID_TARGET)
+
+# Setup breakpoints in main
+bp = target.BreakpointCreateByName("main", "a.out")
+loc = bp.GetLocationAtIndex(0)
+loc_addr = loc.GetAddress()
+func = loc_addr.GetFunction()
+# block = loc_addr.GetBlock()
+range = func.GetRange()
+# block_ranges = block.GetRangeAtIndex(0)

bulbazord wrote:

Please remove the commented out lines in the test (or uncomment them and use 
them)

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Alex Langford via lldb-commits


@@ -0,0 +1,58 @@
+//===-- SBAddressRangeList.h *- C++ 
-*-===//
+//
+// 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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGELIST_H
+#define LLDB_API_SBADDRESSRANGELIST_H
+
+#include 
+
+#include "lldb/API/SBDefines.h"
+
+class AddressRangeListImpl;
+
+namespace lldb {
+
+class LLDB_API SBAddressRangeList {
+public:
+  SBAddressRangeList();
+
+  SBAddressRangeList(const lldb::SBAddressRangeList );
+
+  ~SBAddressRangeList();
+
+  const lldb::SBAddressRangeList &
+  operator=(const lldb::SBAddressRangeList );
+
+  uint32_t GetSize() const;
+
+  void Clear();
+
+  bool GetAddressRangeAtIndex(uint64_t idx, SBAddressRange _range);
+
+  void Append(const lldb::SBAddressRange _range);
+
+  void Append(const lldb::SBAddressRangeList _range_list);
+
+protected:

bulbazord wrote:

In the public API, we can't really do inheritance. These methods should be 
private.

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Alex Langford via lldb-commits

https://github.com/bulbazord requested changes to this pull request.


https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Alex Langford via lldb-commits


@@ -242,6 +244,12 @@ class AddressRange {
   lldb::addr_t m_byte_size = 0; ///< The size in bytes of this address range.
 };
 
+// Forward-declarable wrapper.
+class AddressRanges : public std::vector {
+public:
+  using std::vector::vector;
+};

bulbazord wrote:

Why do you wrap this instead of using `std::vector` 
below?

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Alex Langford via lldb-commits


@@ -0,0 +1,78 @@
+//===-- SBAddressRange.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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRange.h"
+#include "Utils.h"
+#include "lldb/API/SBAddress.h"
+#include "lldb/Core/AddressRange.h"
+#include "lldb/Utility/Instrumentation.h"
+#include 
+#include 
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBAddressRange::SBAddressRange()
+: m_opaque_up(std::make_unique()) {
+  LLDB_INSTRUMENT_VA(this);
+}
+
+SBAddressRange::SBAddressRange(const SBAddressRange ) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  m_opaque_up = clone(rhs.m_opaque_up);
+}
+
+SBAddressRange::SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size)
+: m_opaque_up(std::make_unique(file_addr, byte_size)) {
+  LLDB_INSTRUMENT_VA(this, file_addr, byte_size);
+}
+
+SBAddressRange::~SBAddressRange() = default;
+
+const SBAddressRange ::operator=(const SBAddressRange ) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  if (this != )
+m_opaque_up = clone(rhs.m_opaque_up);
+  return *this;
+}
+
+void SBAddressRange::Clear() {
+  LLDB_INSTRUMENT_VA(this);
+
+  m_opaque_up.reset();
+}
+
+bool SBAddressRange::IsValid() const {
+  return m_opaque_up && m_opaque_up->IsValid();
+}
+
+lldb::SBAddress SBAddressRange::GetBaseAddress() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  assert(m_opaque_up.get() && "AddressRange is NULL");

bulbazord wrote:

We definitely do not want to assert here. Taking down the entire process 
because somebody has an invalid address range and tried to ask for data is 
definitely not a safe solution. In this case, it should return an empty 
SBAddress.

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Alex Langford via lldb-commits


@@ -160,6 +160,17 @@ SBAddress SBFunction::GetEndAddress() {
   return addr;
 }
 
+lldb::SBAddressRange SBFunction::GetRange() {
+  LLDB_INSTRUMENT_VA(this);
+
+  lldb::SBAddressRange range;
+  if (m_opaque_ptr) {
+range.ref() = m_opaque_ptr->GetAddressRange();
+  }

bulbazord wrote:

Remove braces around single line blocks (per LLVM guidelines)

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Alex Langford via lldb-commits


@@ -0,0 +1,58 @@
+//===-- SBAddressRangeList.h *- C++ 
-*-===//
+//
+// 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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGELIST_H
+#define LLDB_API_SBADDRESSRANGELIST_H
+
+#include 
+
+#include "lldb/API/SBDefines.h"
+
+class AddressRangeListImpl;
+
+namespace lldb {
+
+class LLDB_API SBAddressRangeList {
+public:
+  SBAddressRangeList();
+
+  SBAddressRangeList(const lldb::SBAddressRangeList );
+
+  ~SBAddressRangeList();
+
+  const lldb::SBAddressRangeList &
+  operator=(const lldb::SBAddressRangeList );
+
+  uint32_t GetSize() const;
+
+  void Clear();
+
+  bool GetAddressRangeAtIndex(uint64_t idx, SBAddressRange _range);

bulbazord wrote:

Why doesn't this just return `SBAddressRange`? There are then 2 ways to check 
the validity of the range (the return value and what's in `addr_range`).

Also, why is the index `uint64_t` but the return value of GetSize is 
`uint32_t`? Seems like both are related to the possible indices of the list, we 
should pick one and use it everywhere.

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Alex Langford via lldb-commits


@@ -0,0 +1,78 @@
+//===-- SBAddressRange.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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRange.h"
+#include "Utils.h"
+#include "lldb/API/SBAddress.h"
+#include "lldb/Core/AddressRange.h"
+#include "lldb/Utility/Instrumentation.h"
+#include 
+#include 
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBAddressRange::SBAddressRange()
+: m_opaque_up(std::make_unique()) {
+  LLDB_INSTRUMENT_VA(this);
+}
+
+SBAddressRange::SBAddressRange(const SBAddressRange ) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  m_opaque_up = clone(rhs.m_opaque_up);
+}
+
+SBAddressRange::SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size)
+: m_opaque_up(std::make_unique(file_addr, byte_size)) {
+  LLDB_INSTRUMENT_VA(this, file_addr, byte_size);
+}
+
+SBAddressRange::~SBAddressRange() = default;
+
+const SBAddressRange ::operator=(const SBAddressRange ) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  if (this != )
+m_opaque_up = clone(rhs.m_opaque_up);
+  return *this;
+}
+
+void SBAddressRange::Clear() {
+  LLDB_INSTRUMENT_VA(this);
+
+  m_opaque_up.reset();
+}
+
+bool SBAddressRange::IsValid() const {
+  return m_opaque_up && m_opaque_up->IsValid();

bulbazord wrote:

Missing instrumentation macro

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Alex Langford via lldb-commits


@@ -0,0 +1,63 @@
+//===-- SBAddressRange.h *- C++ 
-*-===//
+//
+// 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: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGE_H
+#define LLDB_API_SBADDRESSRANGE_H
+
+#include "lldb/API/SBDefines.h"
+
+namespace lldb {
+
+class LLDB_API SBAddressRange {
+public:
+  SBAddressRange();
+
+  SBAddressRange(const lldb::SBAddressRange );
+
+  SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size);
+
+  ~SBAddressRange();
+
+  const lldb::SBAddressRange =(const lldb::SBAddressRange );
+
+  void Clear();
+
+  bool IsValid() const;
+
+  /// Get the base address of the range.
+  ///
+  /// \return
+  /// Base address object.
+  lldb::SBAddress GetBaseAddress() const;
+
+  /// Get the byte size of this range.
+  ///
+  /// \return
+  /// The size in bytes of this address range.
+  lldb::addr_t GetByteSize() const;
+
+protected:
+  friend class SBAddressRangeList;
+  friend class SBBlock;
+  friend class SBFunction;
+
+  lldb_private::AddressRange ();
+
+  const lldb_private::AddressRange () const;
+
+private:
+  AddressRangeUP m_opaque_up;
+};
+
+#ifndef SWIG
+bool LLDB_API operator==(const SBAddressRange , const SBAddressRange );
+#endif

bulbazord wrote:

Please don't introduce new freestanding operators. This was a mistake when we 
did it in SBAddress and can't really remove it anymore, let's try to limit this.

https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Alex Langford via lldb-commits

https://github.com/bulbazord edited 
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits

https://github.com/royitaqi edited 
https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits


@@ -743,9 +743,28 @@ DebuggerSP 
Debugger::CreateInstance(lldb::LogOutputCallback log_callback,
 }
 
 void Debugger::HandleDestroyCallback() {
-  if (m_destroy_callback) {
-m_destroy_callback(GetID(), m_destroy_callback_baton);
-m_destroy_callback = nullptr;
+  std::lock_guard guard(m_destroy_callback_mutex);
+  const lldb::user_id_t user_id = GetID();
+  // This loop handles the case where callbacks are added/removed by existing
+  // callbacks during the loop, as the following:
+  // - Added callbacks will always be invoked.
+  // - Removed callbacks will never be invoked. That is *unless* the loop
+  //   happens to invoke the said callbacks first, before they get removed.
+  //   In this case, the callbacks gets invoked, and the removal return false.
+  //
+  // In the removal case, because the order of the container is random, it's
+  // wise to not depend on the order and instead implement logic inside the
+  // callbacks to decide if their work should be skipped.
+  while (m_destroy_callback_and_baton.size()) {

royitaqi wrote:

Thought `.size()` is faster because it don't need a negation, i.e. compare to 
`!m_destroy_callback_and_baton.empty()`.

I do agree that the latter has better readability.

https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits


@@ -743,9 +743,28 @@ DebuggerSP 
Debugger::CreateInstance(lldb::LogOutputCallback log_callback,
 }
 
 void Debugger::HandleDestroyCallback() {
-  if (m_destroy_callback) {
-m_destroy_callback(GetID(), m_destroy_callback_baton);
-m_destroy_callback = nullptr;
+  std::lock_guard guard(m_destroy_callback_mutex);
+  const lldb::user_id_t user_id = GetID();
+  // This loop handles the case where callbacks are added/removed by existing
+  // callbacks during the loop, as the following:
+  // - Added callbacks will always be invoked.
+  // - Removed callbacks will never be invoked. That is *unless* the loop
+  //   happens to invoke the said callbacks first, before they get removed.
+  //   In this case, the callbacks gets invoked, and the removal return false.
+  //
+  // In the removal case, because the order of the container is random, it's
+  // wise to not depend on the order and instead implement logic inside the
+  // callbacks to decide if their work should be skipped.
+  while (m_destroy_callback_and_baton.size()) {
+auto iter = m_destroy_callback_and_baton.begin();
+const lldb::destroy_callback_token_t  = iter->first;
+const lldb_private::DebuggerDestroyCallback  = iter->second.first;
+void *const  = iter->second.second;

royitaqi wrote:

I thought these will be inlined because they are only read once. So both (ref 
or copy) have no difference.

I will change them to copy, but am curious to learn the detail here.

https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits


@@ -743,9 +743,28 @@ DebuggerSP 
Debugger::CreateInstance(lldb::LogOutputCallback log_callback,
 }
 
 void Debugger::HandleDestroyCallback() {
-  if (m_destroy_callback) {
-m_destroy_callback(GetID(), m_destroy_callback_baton);
-m_destroy_callback = nullptr;
+  std::lock_guard guard(m_destroy_callback_mutex);
+  const lldb::user_id_t user_id = GetID();
+  // This loop handles the case where callbacks are added/removed by existing
+  // callbacks during the loop, as the following:
+  // - Added callbacks will always be invoked.
+  // - Removed callbacks will never be invoked. That is *unless* the loop
+  //   happens to invoke the said callbacks first, before they get removed.
+  //   In this case, the callbacks gets invoked, and the removal return false.
+  //
+  // In the removal case, because the order of the container is random, it's
+  // wise to not depend on the order and instead implement logic inside the
+  // callbacks to decide if their work should be skipped.
+  while (m_destroy_callback_and_baton.size()) {
+auto iter = m_destroy_callback_and_baton.begin();
+const lldb::destroy_callback_token_t  = iter->first;
+const lldb_private::DebuggerDestroyCallback  = iter->second.first;
+void *const  = iter->second.second;
+callback(user_id, baton);
+// Using `token` to erase, because elements may have been added/removed, 
and
+// that will cause error "invalid iterator access!" if `iter` is used
+// instead.
+m_destroy_callback_and_baton.erase(token);

royitaqi wrote:

The callbacks can add/remove other callbacks while this loop is being executed. 
I.e. the content in the container can change during the loop.

To handle this, the loop always take the first element, call it, then remove 
it, so that the next "first element" will be a new one.

If we don't remove, I wonder how we can make sure that the callbacks which are 
added during the loop are executed.

https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb-dap] Include npm install in the extension installation steps (PR #92028)

2024-05-13 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Walter Erquinigo (walter-erquinigo)


Changes

Otherwise the build step fails due to missing dependencies.


---
Full diff: https://github.com/llvm/llvm-project/pull/92028.diff


1 Files Affected:

- (modified) lldb/tools/lldb-dap/README.md (+2) 


``diff
diff --git a/lldb/tools/lldb-dap/README.md b/lldb/tools/lldb-dap/README.md
index 274b1519208a1..16ce4672be71c 100644
--- a/lldb/tools/lldb-dap/README.md
+++ b/lldb/tools/lldb-dap/README.md
@@ -46,6 +46,7 @@ Installing the plug-in is very straightforward and involves 
just a few steps.
 
 ```bash
 cd /path/to/lldb/tools/lldb-dap
+npm install
 npm run package # This also compiles the extension.
 npm run vscode-install
 ```
@@ -69,6 +70,7 @@ no effect.
 ```bash
 # Bump version in package.json
 cd /path/to/lldb/tools/lldb-dap
+npm install
 npm run package
 npm run vscode-install
 ```

``




https://github.com/llvm/llvm-project/pull/92028
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb-dap] Include npm install in the extension installation steps (PR #92028)

2024-05-13 Thread Walter Erquinigo via lldb-commits

https://github.com/walter-erquinigo created 
https://github.com/llvm/llvm-project/pull/92028

Otherwise the build step fails due to missing dependencies.


>From b065234db18dd726b4e39a98ac0c360e052fe438 Mon Sep 17 00:00:00 2001
From: walter erquinigo 
Date: Mon, 13 May 2024 22:39:47 +0200
Subject: [PATCH] [lldb-dap] Include npm install in the extension installation
 steps

Otherwise the build step fails due to missing dependencies.
---
 lldb/tools/lldb-dap/README.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lldb/tools/lldb-dap/README.md b/lldb/tools/lldb-dap/README.md
index 274b1519208a1..16ce4672be71c 100644
--- a/lldb/tools/lldb-dap/README.md
+++ b/lldb/tools/lldb-dap/README.md
@@ -46,6 +46,7 @@ Installing the plug-in is very straightforward and involves 
just a few steps.
 
 ```bash
 cd /path/to/lldb/tools/lldb-dap
+npm install
 npm run package # This also compiles the extension.
 npm run vscode-install
 ```
@@ -69,6 +70,7 @@ no effect.
 ```bash
 # Bump version in package.json
 cd /path/to/lldb/tools/lldb-dap
+npm install
 npm run package
 npm run vscode-install
 ```

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Improve performance of .debug_names lookups when DW_IDX_parent attributes are used (PR #91808)

2024-05-13 Thread Alexander Yermolovich via lldb-commits

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-commits


[Lldb-commits] [lldb] [LLDB/Coredump] Only take the Pthread from stack start to the stackpointer + red_zone (PR #92002)

2024-05-13 Thread Jacob Lalonde via lldb-commits

https://github.com/Jlalond edited 
https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Miro Bucko via lldb-commits

https://github.com/mbucko updated 
https://github.com/llvm/llvm-project/pull/92014

>From ec177a0cf8c4816f86ab47e77f29e3fdf37323fd Mon Sep 17 00:00:00 2001
From: Miro Bucko 
Date: Fri, 10 May 2024 12:42:03 -0700
Subject: [PATCH] Add AddressRange to SB API

Summary:
This adds new SB API calls and classes to allow a user of the SB API to
obtain an address range from SBFunction and SBBlock.

Test Plan:

Reviewers: clayborg

Subscribers: lldb-commits

Tasks:

Tags:
---
 lldb/bindings/headers.swig|   2 +
 .../interface/SBAddressRangeDocstrings.i  |   3 +
 .../interface/SBAddressRangeListDocstrings.i  |   3 +
 .../interface/SBAddressRangeListExtensions.i  |  13 ++
 lldb/bindings/interfaces.swig |   2 +
 lldb/include/lldb/API/LLDB.h  |   2 +
 lldb/include/lldb/API/SBAddress.h |   1 +
 lldb/include/lldb/API/SBAddressRange.h|  63 +
 lldb/include/lldb/API/SBAddressRangeList.h|  58 
 lldb/include/lldb/API/SBBlock.h   |   3 +
 lldb/include/lldb/API/SBDefines.h |   2 +
 lldb/include/lldb/API/SBFunction.h|   3 +
 lldb/include/lldb/Core/AddressRange.h |   8 ++
 lldb/include/lldb/lldb-forward.h  |   3 +
 lldb/source/API/CMakeLists.txt|   2 +
 lldb/source/API/SBAddressRange.cpp|  78 +++
 lldb/source/API/SBAddressRangeList.cpp| 130 ++
 lldb/source/API/SBBlock.cpp   |  10 ++
 lldb/source/API/SBFunction.cpp|  11 ++
 lldb/source/Core/AddressRange.cpp |   4 +
 .../API/python_api/address_range/Makefile |   3 +
 .../address_range/TestAddressRange.py | 124 +
 .../API/python_api/address_range/main.cpp |   3 +
 23 files changed, 531 insertions(+)
 create mode 100644 lldb/bindings/interface/SBAddressRangeDocstrings.i
 create mode 100644 lldb/bindings/interface/SBAddressRangeListDocstrings.i
 create mode 100644 lldb/bindings/interface/SBAddressRangeListExtensions.i
 create mode 100644 lldb/include/lldb/API/SBAddressRange.h
 create mode 100644 lldb/include/lldb/API/SBAddressRangeList.h
 create mode 100644 lldb/source/API/SBAddressRange.cpp
 create mode 100644 lldb/source/API/SBAddressRangeList.cpp
 create mode 100644 lldb/test/API/python_api/address_range/Makefile
 create mode 100644 lldb/test/API/python_api/address_range/TestAddressRange.py
 create mode 100644 lldb/test/API/python_api/address_range/main.cpp

diff --git a/lldb/bindings/headers.swig b/lldb/bindings/headers.swig
index e8d0cda288141..2b53eefc8568b 100644
--- a/lldb/bindings/headers.swig
+++ b/lldb/bindings/headers.swig
@@ -8,6 +8,8 @@
 %{
 #include "lldb/lldb-public.h"
 #include "lldb/API/SBAddress.h"
+#include "lldb/API/SBAddressRange.h"
+#include "lldb/API/SBAddressRangeList.h"
 #include "lldb/API/SBAttachInfo.h"
 #include "lldb/API/SBBlock.h"
 #include "lldb/API/SBBreakpoint.h"
diff --git a/lldb/bindings/interface/SBAddressRangeDocstrings.i 
b/lldb/bindings/interface/SBAddressRangeDocstrings.i
new file mode 100644
index 0..650195704d73e
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeDocstrings.i
@@ -0,0 +1,3 @@
+%feature("docstring",
+"API clients can get address range information."
+) lldb::SBAddressRange;
diff --git a/lldb/bindings/interface/SBAddressRangeListDocstrings.i 
b/lldb/bindings/interface/SBAddressRangeListDocstrings.i
new file mode 100644
index 0..e4b96b9ca5931
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeListDocstrings.i
@@ -0,0 +1,3 @@
+%feature("docstring",
+"Represents a list of :py:class:`SBAddressRange`."
+) lldb::SBAddressRangeList;
diff --git a/lldb/bindings/interface/SBAddressRangeListExtensions.i 
b/lldb/bindings/interface/SBAddressRangeListExtensions.i
new file mode 100644
index 0..781780b15e877
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeListExtensions.i
@@ -0,0 +1,13 @@
+%extend lldb::SBAddressRangeList {
+#ifdef SWIGPYTHON
+%pythoncode%{
+def __len__(self):
+  '''Return the number of address ranges in a lldb.SBAddressRangeList 
object.'''
+  return self.GetSize()
+
+def __iter__(self):
+  '''Iterate over all the address ranges in a lldb.SBAddressRangeList 
object.'''
+  return lldb_iter(self, 'GetSize', 'GetAddressRangeAtIndex')
+%}
+#endif
+}
diff --git a/lldb/bindings/interfaces.swig b/lldb/bindings/interfaces.swig
index a31a0b4af1eb6..b9aae318d0684 100644
--- a/lldb/bindings/interfaces.swig
+++ b/lldb/bindings/interfaces.swig
@@ -86,6 +86,8 @@
 
 /* API headers */
 %include "lldb/API/SBAddress.h"
+%include "lldb/API/SBAddressRange.h"
+%include "lldb/API/SBAddressRangeList.h"
 %include "lldb/API/SBAttachInfo.h"
 %include "lldb/API/SBBlock.h"
 %include "lldb/API/SBBreakpoint.h"
diff --git a/lldb/include/lldb/API/LLDB.h b/lldb/include/lldb/API/LLDB.h
index b256544326a22..d8cc9f5067fe9 100644
--- a/lldb/include/lldb/API/LLDB.h
+++ 

[Lldb-commits] [lldb] [lldb] Add CMake dependency tracking for SBLanguages generation script (PR #91686)

2024-05-13 Thread Alex Langford via lldb-commits

https://github.com/bulbazord closed 
https://github.com/llvm/llvm-project/pull/91686
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] fd4b5f4 - [lldb] Add CMake dependency tracking for SBLanguages generation script (#91686)

2024-05-13 Thread via lldb-commits

Author: Alex Langford
Date: 2024-05-13T12:32:16-07:00
New Revision: fd4b5f4b52e414bb6fee7c906a22867891fb46b5

URL: 
https://github.com/llvm/llvm-project/commit/fd4b5f4b52e414bb6fee7c906a22867891fb46b5
DIFF: 
https://github.com/llvm/llvm-project/commit/fd4b5f4b52e414bb6fee7c906a22867891fb46b5.diff

LOG: [lldb] Add CMake dependency tracking for SBLanguages generation script 
(#91686)

If you change the generation script and re-run ninja (or whatever drives
your build), it currently will not regenerate SBLanguages.h. With
dependency tracking, it should re-run when the script changes.

Added: 


Modified: 
lldb/source/API/CMakeLists.txt

Removed: 




diff  --git a/lldb/source/API/CMakeLists.txt b/lldb/source/API/CMakeLists.txt
index aa31caddfde3a..76b42ecf63f91 100644
--- a/lldb/source/API/CMakeLists.txt
+++ b/lldb/source/API/CMakeLists.txt
@@ -23,14 +23,17 @@ endif()
 # Generate SBLanguages.h from Dwarf.def.
 set(sb_languages_file
   ${CMAKE_CURRENT_BINARY_DIR}/../../include/lldb/API/SBLanguages.h)
+set(sb_languages_generator
+  ${LLDB_SOURCE_DIR}/scripts/generate-sbapi-dwarf-enum.py)
 add_custom_command(
   COMMENT "Generating SBLanguages.h from Dwarf.def"
   COMMAND "${Python3_EXECUTABLE}"
-  ${LLDB_SOURCE_DIR}/scripts/generate-sbapi-dwarf-enum.py
+  ${sb_languages_generator}
   ${LLVM_MAIN_INCLUDE_DIR}/llvm/BinaryFormat/Dwarf.def
   -o ${sb_languages_file}
   OUTPUT ${sb_languages_file}
   DEPENDS ${LLVM_MAIN_INCLUDE_DIR}/llvm/BinaryFormat/Dwarf.def
+  ${sb_languages_generator}
   WORKING_DIRECTORY ${LLVM_LIBRARY_OUTPUT_INTDIR}
 )
 add_custom_target(lldb-sbapi-dwarf-enums



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread via lldb-commits

github-actions[bot] wrote:




:warning: C/C++ code formatter, clang-format found issues in your code. 
:warning:



You can test this locally with the following command:


``bash
git-clang-format --diff a037d88929460ff9571927c56d6db215be086149 
309050cf7cecab87b851e5d70f5f7437577a828f -- 
lldb/include/lldb/API/SBAddressRange.h 
lldb/include/lldb/API/SBAddressRangeList.h lldb/source/API/SBAddressRange.cpp 
lldb/source/API/SBAddressRangeList.cpp 
lldb/test/API/python_api/address_range/main.cpp lldb/include/lldb/API/LLDB.h 
lldb/include/lldb/API/SBAddress.h lldb/include/lldb/API/SBBlock.h 
lldb/include/lldb/API/SBDefines.h lldb/include/lldb/API/SBFunction.h 
lldb/include/lldb/Core/AddressRange.h lldb/include/lldb/lldb-forward.h 
lldb/source/API/SBBlock.cpp lldb/source/API/SBFunction.cpp 
lldb/source/Core/AddressRange.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/include/lldb/API/SBAddressRangeList.h 
b/lldb/include/lldb/API/SBAddressRangeList.h
index 81dab4a88d..f6d7f170d9 100644
--- a/lldb/include/lldb/API/SBAddressRangeList.h
+++ b/lldb/include/lldb/API/SBAddressRangeList.h
@@ -25,7 +25,8 @@ public:
 
   ~SBAddressRangeList();
 
-  const lldb::SBAddressRangeList =(const lldb::SBAddressRangeList 
);
+  const lldb::SBAddressRangeList &
+  operator=(const lldb::SBAddressRangeList );
 
   uint32_t GetSize() const;
 
@@ -41,7 +42,7 @@ protected:
   const AddressRangeListImpl *operator->() const;
 
   const AddressRangeListImpl *() const;
-  
+
 private:
   friend class SBProcess;
 
diff --git a/lldb/source/API/SBAddressRange.cpp 
b/lldb/source/API/SBAddressRange.cpp
index 8fce0efb3e..54622f40c7 100644
--- a/lldb/source/API/SBAddressRange.cpp
+++ b/lldb/source/API/SBAddressRange.cpp
@@ -7,10 +7,10 @@
 
//===--===//
 
 #include "lldb/API/SBAddressRange.h"
+#include "Utils.h"
 #include "lldb/API/SBAddress.h"
 #include "lldb/Core/AddressRange.h"
 #include "lldb/Utility/Instrumentation.h"
-#include "Utils.h"
 #include 
 #include 
 
@@ -29,7 +29,7 @@ SBAddressRange::SBAddressRange(const SBAddressRange ) {
 }
 
 SBAddressRange::SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size)
-  : m_opaque_up(std::make_unique(file_addr, byte_size)) {
+: m_opaque_up(std::make_unique(file_addr, byte_size)) {
   LLDB_INSTRUMENT_VA(this, file_addr, byte_size);
 }
 
diff --git a/lldb/source/API/SBAddressRangeList.cpp 
b/lldb/source/API/SBAddressRangeList.cpp
index 6226c4659a..5841d9cfc5 100644
--- a/lldb/source/API/SBAddressRangeList.cpp
+++ b/lldb/source/API/SBAddressRangeList.cpp
@@ -8,10 +8,10 @@
 
//===--===//
 
 #include "lldb/API/SBAddressRangeList.h"
+#include "Utils.h"
 #include "lldb/API/SBAddressRange.h"
 #include "lldb/Core/AddressRange.h"
 #include "lldb/Utility/Instrumentation.h"
-#include "Utils.h"
 
 using namespace lldb;
 using namespace lldb_private;
@@ -72,16 +72,15 @@ SBAddressRangeList::SBAddressRangeList()
   LLDB_INSTRUMENT_VA(this);
 }
 
-SBAddressRangeList::SBAddressRangeList(
-const SBAddressRangeList )
+SBAddressRangeList::SBAddressRangeList(const SBAddressRangeList )
 : m_opaque_up(new AddressRangeListImpl(*rhs.m_opaque_up)) {
   LLDB_INSTRUMENT_VA(this, rhs);
 }
 
 SBAddressRangeList::~SBAddressRangeList() = default;
 
-const SBAddressRangeList ::
-operator=(const SBAddressRangeList ) {
+const SBAddressRangeList &
+SBAddressRangeList::operator=(const SBAddressRangeList ) {
   LLDB_INSTRUMENT_VA(this, rhs);
 
   if (this != ) {
@@ -96,8 +95,8 @@ uint32_t SBAddressRangeList::GetSize() const {
   return m_opaque_up->GetSize();
 }
 
-bool SBAddressRangeList::GetAddressRangeAtIndex(
-uint64_t idx, SBAddressRange _range) {
+bool SBAddressRangeList::GetAddressRangeAtIndex(uint64_t idx,
+SBAddressRange _range) {
   LLDB_INSTRUMENT_VA(this, idx, addr_range);
 
   return m_opaque_up->GetAddressRangeAtIndex(idx, addr_range.ref());
diff --git a/lldb/source/API/SBFunction.cpp b/lldb/source/API/SBFunction.cpp
index 4f91635737..74bd7eab08 100644
--- a/lldb/source/API/SBFunction.cpp
+++ b/lldb/source/API/SBFunction.cpp
@@ -162,7 +162,7 @@ SBAddress SBFunction::GetEndAddress() {
 
 lldb::SBAddressRange SBFunction::GetRange() {
   LLDB_INSTRUMENT_VA(this);
-  
+
   lldb::SBAddressRange range;
   if (m_opaque_ptr) {
 range.ref() = m_opaque_ptr->GetAddressRange();
diff --git a/lldb/test/API/python_api/address_range/main.cpp 
b/lldb/test/API/python_api/address_range/main.cpp
index cdd6db20bf..e8230f71e4 100644
--- a/lldb/test/API/python_api/address_range/main.cpp
+++ b/lldb/test/API/python_api/address_range/main.cpp
@@ -1,5 +1,3 @@
 #include 
 
-int main() {
-std::cout << "Hello World!" << std::endl;
-}
+int main() { std::cout << "Hello World!" << std::endl; }

``




https://github.com/llvm/llvm-project/pull/92014

[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Miro Bucko (mbucko)


Changes

Summary:
This adds new SB API calls and classes to allow a user of the SB API to obtain 
an address range from SBFunction and SBBlock.

Test Plan:

Reviewers: clayborg

Subscribers: lldb-commits

Tasks:

Tags:

---

Patch is 23.20 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/92014.diff


23 Files Affected:

- (modified) lldb/bindings/headers.swig (+2) 
- (added) lldb/bindings/interface/SBAddressRangeDocstrings.i (+3) 
- (added) lldb/bindings/interface/SBAddressRangeListDocstrings.i (+3) 
- (added) lldb/bindings/interface/SBAddressRangeListExtensions.i (+13) 
- (modified) lldb/bindings/interfaces.swig (+2) 
- (modified) lldb/include/lldb/API/LLDB.h (+2) 
- (modified) lldb/include/lldb/API/SBAddress.h (+1) 
- (added) lldb/include/lldb/API/SBAddressRange.h (+63) 
- (added) lldb/include/lldb/API/SBAddressRangeList.h (+57) 
- (modified) lldb/include/lldb/API/SBBlock.h (+3) 
- (modified) lldb/include/lldb/API/SBDefines.h (+2) 
- (modified) lldb/include/lldb/API/SBFunction.h (+3) 
- (modified) lldb/include/lldb/Core/AddressRange.h (+8) 
- (modified) lldb/include/lldb/lldb-forward.h (+3) 
- (modified) lldb/source/API/CMakeLists.txt (+2) 
- (added) lldb/source/API/SBAddressRange.cpp (+78) 
- (added) lldb/source/API/SBAddressRangeList.cpp (+131) 
- (modified) lldb/source/API/SBBlock.cpp (+10) 
- (modified) lldb/source/API/SBFunction.cpp (+11) 
- (modified) lldb/source/Core/AddressRange.cpp (+4) 
- (added) lldb/test/API/python_api/address_range/Makefile (+3) 
- (added) lldb/test/API/python_api/address_range/TestAddressRange.py (+124) 
- (added) lldb/test/API/python_api/address_range/main.cpp (+5) 


``diff
diff --git a/lldb/bindings/headers.swig b/lldb/bindings/headers.swig
index e8d0cda288141..2b53eefc8568b 100644
--- a/lldb/bindings/headers.swig
+++ b/lldb/bindings/headers.swig
@@ -8,6 +8,8 @@
 %{
 #include "lldb/lldb-public.h"
 #include "lldb/API/SBAddress.h"
+#include "lldb/API/SBAddressRange.h"
+#include "lldb/API/SBAddressRangeList.h"
 #include "lldb/API/SBAttachInfo.h"
 #include "lldb/API/SBBlock.h"
 #include "lldb/API/SBBreakpoint.h"
diff --git a/lldb/bindings/interface/SBAddressRangeDocstrings.i 
b/lldb/bindings/interface/SBAddressRangeDocstrings.i
new file mode 100644
index 0..650195704d73e
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeDocstrings.i
@@ -0,0 +1,3 @@
+%feature("docstring",
+"API clients can get address range information."
+) lldb::SBAddressRange;
diff --git a/lldb/bindings/interface/SBAddressRangeListDocstrings.i 
b/lldb/bindings/interface/SBAddressRangeListDocstrings.i
new file mode 100644
index 0..e4b96b9ca5931
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeListDocstrings.i
@@ -0,0 +1,3 @@
+%feature("docstring",
+"Represents a list of :py:class:`SBAddressRange`."
+) lldb::SBAddressRangeList;
diff --git a/lldb/bindings/interface/SBAddressRangeListExtensions.i 
b/lldb/bindings/interface/SBAddressRangeListExtensions.i
new file mode 100644
index 0..781780b15e877
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeListExtensions.i
@@ -0,0 +1,13 @@
+%extend lldb::SBAddressRangeList {
+#ifdef SWIGPYTHON
+%pythoncode%{
+def __len__(self):
+  '''Return the number of address ranges in a lldb.SBAddressRangeList 
object.'''
+  return self.GetSize()
+
+def __iter__(self):
+  '''Iterate over all the address ranges in a lldb.SBAddressRangeList 
object.'''
+  return lldb_iter(self, 'GetSize', 'GetAddressRangeAtIndex')
+%}
+#endif
+}
diff --git a/lldb/bindings/interfaces.swig b/lldb/bindings/interfaces.swig
index a31a0b4af1eb6..b9aae318d0684 100644
--- a/lldb/bindings/interfaces.swig
+++ b/lldb/bindings/interfaces.swig
@@ -86,6 +86,8 @@
 
 /* API headers */
 %include "lldb/API/SBAddress.h"
+%include "lldb/API/SBAddressRange.h"
+%include "lldb/API/SBAddressRangeList.h"
 %include "lldb/API/SBAttachInfo.h"
 %include "lldb/API/SBBlock.h"
 %include "lldb/API/SBBreakpoint.h"
diff --git a/lldb/include/lldb/API/LLDB.h b/lldb/include/lldb/API/LLDB.h
index b256544326a22..d8cc9f5067fe9 100644
--- a/lldb/include/lldb/API/LLDB.h
+++ b/lldb/include/lldb/API/LLDB.h
@@ -10,6 +10,8 @@
 #define LLDB_API_LLDB_H
 
 #include "lldb/API/SBAddress.h"
+#include "lldb/API/SBAddressRange.h"
+#include "lldb/API/SBAddressRangeList.h"
 #include "lldb/API/SBAttachInfo.h"
 #include "lldb/API/SBBlock.h"
 #include "lldb/API/SBBreakpoint.h"
diff --git a/lldb/include/lldb/API/SBAddress.h 
b/lldb/include/lldb/API/SBAddress.h
index 5e5f355ccc390..430dad4862dbf 100644
--- a/lldb/include/lldb/API/SBAddress.h
+++ b/lldb/include/lldb/API/SBAddress.h
@@ -86,6 +86,7 @@ class LLDB_API SBAddress {
   lldb::SBLineEntry GetLineEntry();
 
 protected:
+  friend class SBAddressRange;
   friend class SBBlock;
   friend class SBBreakpoint;
   friend class SBBreakpointLocation;
diff --git 

[Lldb-commits] [lldb] Improve performance of .debug_names lookups when DW_IDX_parent attributes are used (PR #91808)

2024-05-13 Thread David Blaikie via lldb-commits

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). 
> In such a case, a parent attribute may point to a nameless index entry (that 
> is, one that cannot be reached from any entry in the name table), or it may 
> point to the nearest ancestor that does have an index entry

So I think you could have a parent that's a declaration, represented as a 
nameless index entry. That'd allow faster comparisons when examining the entry 
for the named child that had such a parent - because you could potentially 
check that named entry's fully qualified name directly from the named entry and 
the parents - without needing to parse all the DIEs in the CU to walk and find 
the start of the parents.

But I don't believe clang is producing such DWARF today.

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-commits


[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

2024-05-13 Thread Miro Bucko via lldb-commits

https://github.com/mbucko created 
https://github.com/llvm/llvm-project/pull/92014

Summary:
This adds new SB API calls and classes to allow a user of the SB API to obtain 
an address range from SBFunction and SBBlock.

Test Plan:

Reviewers: clayborg

Subscribers: lldb-commits

Tasks:

Tags:

>From 309050cf7cecab87b851e5d70f5f7437577a828f Mon Sep 17 00:00:00 2001
From: Miro Bucko 
Date: Fri, 10 May 2024 12:42:03 -0700
Subject: [PATCH] Add AddressRange to SB API

Summary:
This adds new SB API calls and classes to allow a user of the SB API to
obtain an address range from SBFunction and SBBlock.

Test Plan:

Reviewers: clayborg

Subscribers: lldb-commits

Tasks:

Tags:
---
 lldb/bindings/headers.swig|   2 +
 .../interface/SBAddressRangeDocstrings.i  |   3 +
 .../interface/SBAddressRangeListDocstrings.i  |   3 +
 .../interface/SBAddressRangeListExtensions.i  |  13 ++
 lldb/bindings/interfaces.swig |   2 +
 lldb/include/lldb/API/LLDB.h  |   2 +
 lldb/include/lldb/API/SBAddress.h |   1 +
 lldb/include/lldb/API/SBAddressRange.h|  63 +
 lldb/include/lldb/API/SBAddressRangeList.h|  57 
 lldb/include/lldb/API/SBBlock.h   |   3 +
 lldb/include/lldb/API/SBDefines.h |   2 +
 lldb/include/lldb/API/SBFunction.h|   3 +
 lldb/include/lldb/Core/AddressRange.h |   8 ++
 lldb/include/lldb/lldb-forward.h  |   3 +
 lldb/source/API/CMakeLists.txt|   2 +
 lldb/source/API/SBAddressRange.cpp|  78 +++
 lldb/source/API/SBAddressRangeList.cpp| 131 ++
 lldb/source/API/SBBlock.cpp   |  10 ++
 lldb/source/API/SBFunction.cpp|  11 ++
 lldb/source/Core/AddressRange.cpp |   4 +
 .../API/python_api/address_range/Makefile |   3 +
 .../address_range/TestAddressRange.py | 124 +
 .../API/python_api/address_range/main.cpp |   5 +
 23 files changed, 533 insertions(+)
 create mode 100644 lldb/bindings/interface/SBAddressRangeDocstrings.i
 create mode 100644 lldb/bindings/interface/SBAddressRangeListDocstrings.i
 create mode 100644 lldb/bindings/interface/SBAddressRangeListExtensions.i
 create mode 100644 lldb/include/lldb/API/SBAddressRange.h
 create mode 100644 lldb/include/lldb/API/SBAddressRangeList.h
 create mode 100644 lldb/source/API/SBAddressRange.cpp
 create mode 100644 lldb/source/API/SBAddressRangeList.cpp
 create mode 100644 lldb/test/API/python_api/address_range/Makefile
 create mode 100644 lldb/test/API/python_api/address_range/TestAddressRange.py
 create mode 100644 lldb/test/API/python_api/address_range/main.cpp

diff --git a/lldb/bindings/headers.swig b/lldb/bindings/headers.swig
index e8d0cda288141..2b53eefc8568b 100644
--- a/lldb/bindings/headers.swig
+++ b/lldb/bindings/headers.swig
@@ -8,6 +8,8 @@
 %{
 #include "lldb/lldb-public.h"
 #include "lldb/API/SBAddress.h"
+#include "lldb/API/SBAddressRange.h"
+#include "lldb/API/SBAddressRangeList.h"
 #include "lldb/API/SBAttachInfo.h"
 #include "lldb/API/SBBlock.h"
 #include "lldb/API/SBBreakpoint.h"
diff --git a/lldb/bindings/interface/SBAddressRangeDocstrings.i 
b/lldb/bindings/interface/SBAddressRangeDocstrings.i
new file mode 100644
index 0..650195704d73e
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeDocstrings.i
@@ -0,0 +1,3 @@
+%feature("docstring",
+"API clients can get address range information."
+) lldb::SBAddressRange;
diff --git a/lldb/bindings/interface/SBAddressRangeListDocstrings.i 
b/lldb/bindings/interface/SBAddressRangeListDocstrings.i
new file mode 100644
index 0..e4b96b9ca5931
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeListDocstrings.i
@@ -0,0 +1,3 @@
+%feature("docstring",
+"Represents a list of :py:class:`SBAddressRange`."
+) lldb::SBAddressRangeList;
diff --git a/lldb/bindings/interface/SBAddressRangeListExtensions.i 
b/lldb/bindings/interface/SBAddressRangeListExtensions.i
new file mode 100644
index 0..781780b15e877
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeListExtensions.i
@@ -0,0 +1,13 @@
+%extend lldb::SBAddressRangeList {
+#ifdef SWIGPYTHON
+%pythoncode%{
+def __len__(self):
+  '''Return the number of address ranges in a lldb.SBAddressRangeList 
object.'''
+  return self.GetSize()
+
+def __iter__(self):
+  '''Iterate over all the address ranges in a lldb.SBAddressRangeList 
object.'''
+  return lldb_iter(self, 'GetSize', 'GetAddressRangeAtIndex')
+%}
+#endif
+}
diff --git a/lldb/bindings/interfaces.swig b/lldb/bindings/interfaces.swig
index a31a0b4af1eb6..b9aae318d0684 100644
--- a/lldb/bindings/interfaces.swig
+++ b/lldb/bindings/interfaces.swig
@@ -86,6 +86,8 @@
 
 /* API headers */
 %include "lldb/API/SBAddress.h"
+%include "lldb/API/SBAddressRange.h"
+%include "lldb/API/SBAddressRangeList.h"
 %include "lldb/API/SBAttachInfo.h"
 %include "lldb/API/SBBlock.h"
 

[Lldb-commits] [lldb] Improve performance of .debug_names lookups when DW_IDX_parent attributes are used (PR #91808)

2024-05-13 Thread David Blaikie via 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: 
https://godbolt.org/z/efjbze3x1

it'd be good to have a reproducer for this to motivate the discussion... 

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-commits


[Lldb-commits] [lldb] [lldb][TypeSystem][NFCI] Log creation of new TypeSystem instances to expression log (PR #91985)

2024-05-13 Thread Michael Buch via lldb-commits

https://github.com/Michael137 closed 
https://github.com/llvm/llvm-project/pull/91985
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] dc7ce3b - [lldb][TypeSystem][NFCI] Log creation of new TypeSystem instances to expression log (#91985)

2024-05-13 Thread via lldb-commits

Author: Michael Buch
Date: 2024-05-13T19:12:49+01:00
New Revision: dc7ce3b41c936c4cc189b4bbf6a2e3b5475d9fc5

URL: 
https://github.com/llvm/llvm-project/commit/dc7ce3b41c936c4cc189b4bbf6a2e3b5475d9fc5
DIFF: 
https://github.com/llvm/llvm-project/commit/dc7ce3b41c936c4cc189b4bbf6a2e3b5475d9fc5.diff

LOG: [lldb][TypeSystem][NFCI] Log creation of new TypeSystem instances to 
expression log (#91985)

We emit `ASTContext` and `TypeSystem` pointers into the `expr` log but
there is no easy way (that I know of) to correlate the pointer value
back to an easily readible form. This patch simply logs the name of the
`TypeSystem` and the associated `ASTContext` into the `expr` channel
whenever we create a new `TypeSystemClang`.

The following is an example of the new log entries:
```
$ grep Created /tmp/lldb.log 
 Created new TypeSystem for (ASTContext*)0x000101a2e200 'ASTContext for 
'/Users/michaelbuch/a.out''
 Created new TypeSystem for (ASTContext*)0x000102512a00 'scratch ASTContext'
 Created new TypeSystem for (ASTContext*)0x000102116a00 
'ClangModulesDeclVendor ASTContext'
 Created new TypeSystem for (ASTContext*)0x0001022e8c00 'Expression 
ASTContext for '''
 Created new TypeSystem for (ASTContext*)0x0001103e7200 
'AppleObjCTypeEncodingParser ASTContext'
 Created new TypeSystem for (ASTContext*)0x0001103f7000 
'AppleObjCDeclVendor AST'
 Created new TypeSystem for (ASTContext*)0x0001104bfe00 'Expression 
ASTContext for '''
 Created new TypeSystem for (ASTContext*)0x000101f01000 'Expression 
ASTContext for '''
 Created new TypeSystem for (ASTContext*)0x0001025d3c00 'Expression 
ASTContext for '''
 Created new TypeSystem for (ASTContext*)0x000110422400 'Expression 
ASTContext for '''
 Created new TypeSystem for (ASTContext*)0x00011602c200 'Expression 
ASTContext for '''
 Created new TypeSystem for (ASTContext*)0x000110641600 'Expression 
ASTContext for '''
 Created new TypeSystem for (ASTContext*)0x000110617400 'Expression 
ASTContext for '''
```

Added: 


Modified: 
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h

Removed: 




diff  --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index d0033fcd9cdfc..17a9c675fbba4 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -501,6 +501,8 @@ TypeSystemClang::TypeSystemClang(llvm::StringRef name,
   // The caller didn't pass an ASTContext so create a new one for this
   // TypeSystemClang.
   CreateASTContext();
+
+  LogCreation();
 }
 
 TypeSystemClang::TypeSystemClang(llvm::StringRef name,
@@ -510,6 +512,8 @@ TypeSystemClang::TypeSystemClang(llvm::StringRef name,
 
   m_ast_up.reset(_ctxt);
   GetASTMap().Insert(_ctxt, this);
+
+  LogCreation();
 }
 
 // Destructor
@@ -630,7 +634,7 @@ void TypeSystemClang::SetExternalSource(
   ast.setExternalSource(ast_source_up);
 }
 
-ASTContext ::getASTContext() {
+ASTContext ::getASTContext() const {
   assert(m_ast_up);
   return *m_ast_up;
 }
@@ -9750,3 +9754,9 @@ bool TypeSystemClang::SetDeclIsForcefullyCompleted(const 
clang::TagDecl *td) {
   metadata->SetIsForcefullyCompleted();
   return true;
 }
+
+void TypeSystemClang::LogCreation() const {
+  if (auto *log = GetLog(LLDBLog::Expressions))
+LLDB_LOG(log, "Created new TypeSystem for (ASTContext*){0:x} '{1}'",
+ (), getDisplayName());
+}

diff  --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
index 59ca69622d9e8..042379d40bcb3 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
@@ -162,7 +162,7 @@ class TypeSystemClang : public TypeSystem {
   llvm::StringRef getDisplayName() const { return m_display_name; }
 
   /// Returns the clang::ASTContext instance managed by this TypeSystemClang.
-  clang::ASTContext ();
+  clang::ASTContext () const;
 
   clang::MangleContext *getMangleContext();
 
@@ -1166,6 +1166,12 @@ class TypeSystemClang : public TypeSystem {
   bool IsTypeImpl(lldb::opaque_compiler_type_t type,
   llvm::function_ref predicate) const;
 
+  /// Emits information about this TypeSystem into the expression log.
+  ///
+  /// Helper method that is used in \ref TypeSystemClang::TypeSystemClang
+  /// on creation of a new instance.
+  void LogCreation() const;
+
   // Classes that inherit from TypeSystemClang can see and modify these
   std::string m_target_triple;
   std::unique_ptr m_ast_up;



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][TypeSystem][NFCI] Log creation of new TypeSystem instances to expression log (PR #91985)

2024-05-13 Thread Michael Buch via lldb-commits

https://github.com/Michael137 updated 
https://github.com/llvm/llvm-project/pull/91985

>From 1ccf935f97b21e0bd87955f3313cb47261d11379 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Mon, 13 May 2024 15:34:24 +0100
Subject: [PATCH 1/3] [lldb][TypeSystem][NFCI] Log creation of new TypeSystem
 instances to expression log

We emit `ASTContext` and `TypeSystem` pointers into the `expr` log
but there is no easy way (that I know of) to correlate the pointer
value back to an easily readible form. This patch simply logs the name
of the `TypeSystem` and the associated `ASTContext` into the `expr`
channel whenever we create a new `TypeSystemClang`.
---
 .../TypeSystem/Clang/TypeSystemClang.cpp  | 21 +++
 .../TypeSystem/Clang/TypeSystemClang.h|  4 +++-
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index d0033fcd9cdfc..a7b5c55098de2 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -501,6 +501,8 @@ TypeSystemClang::TypeSystemClang(llvm::StringRef name,
   // The caller didn't pass an ASTContext so create a new one for this
   // TypeSystemClang.
   CreateASTContext();
+
+  LogCreation();
 }
 
 TypeSystemClang::TypeSystemClang(llvm::StringRef name,
@@ -510,6 +512,8 @@ TypeSystemClang::TypeSystemClang(llvm::StringRef name,
 
   m_ast_up.reset(_ctxt);
   GetASTMap().Insert(_ctxt, this);
+
+  LogCreation();
 }
 
 // Destructor
@@ -544,13 +548,16 @@ lldb::TypeSystemSP 
TypeSystemClang::CreateInstance(lldb::LanguageType language,
 }
   }
 
+  lldb::TypeSystemSP instance;
+
   if (module) {
 std::string ast_name =
 "ASTContext for '" + module->GetFileSpec().GetPath() + "'";
-return std::make_shared(ast_name, triple);
+instance = std::make_shared(ast_name, triple);
   } else if (target && target->IsValid())
-return std::make_shared(*target, triple);
-  return lldb::TypeSystemSP();
+instance = std::make_shared(*target, triple);
+
+  return instance;
 }
 
 LanguageSet TypeSystemClang::GetSupportedLanguagesForTypes() {
@@ -630,7 +637,7 @@ void TypeSystemClang::SetExternalSource(
   ast.setExternalSource(ast_source_up);
 }
 
-ASTContext ::getASTContext() {
+ASTContext ::getASTContext() const {
   assert(m_ast_up);
   return *m_ast_up;
 }
@@ -9750,3 +9757,9 @@ bool TypeSystemClang::SetDeclIsForcefullyCompleted(const 
clang::TagDecl *td) {
   metadata->SetIsForcefullyCompleted();
   return true;
 }
+
+void TypeSystemClang::LogCreation() const {
+  if (auto *log = GetLog(LLDBLog::Expressions))
+LLDB_LOG(log, "Created new TypeSystem for (ASTContext*){0:x} '{1}'",
+ (), getDisplayName());
+}
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
index 59ca69622d9e8..6ba2c44c36584 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
@@ -162,7 +162,7 @@ class TypeSystemClang : public TypeSystem {
   llvm::StringRef getDisplayName() const { return m_display_name; }
 
   /// Returns the clang::ASTContext instance managed by this TypeSystemClang.
-  clang::ASTContext ();
+  clang::ASTContext () const;
 
   clang::MangleContext *getMangleContext();
 
@@ -1166,6 +1166,8 @@ class TypeSystemClang : public TypeSystem {
   bool IsTypeImpl(lldb::opaque_compiler_type_t type,
   llvm::function_ref predicate) const;
 
+  void LogCreation() const;
+
   // Classes that inherit from TypeSystemClang can see and modify these
   std::string m_target_triple;
   std::unique_ptr m_ast_up;

>From 8cb97736d9ba9bd2f1a0bc10f96c3ad7b9f9f59f Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Mon, 13 May 2024 17:19:21 +0100
Subject: [PATCH 2/3] fixup! revert obsolete changes

---
 lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index a7b5c55098de2..8b9ef98071e68 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -548,16 +548,14 @@ lldb::TypeSystemSP 
TypeSystemClang::CreateInstance(lldb::LanguageType language,
 }
   }
 
-  lldb::TypeSystemSP instance;
-
   if (module) {
 std::string ast_name =
 "ASTContext for '" + module->GetFileSpec().GetPath() + "'";
-instance = std::make_shared(ast_name, triple);
+return std::make_shared(ast_name, triple);
   } else if (target && target->IsValid())
-instance = std::make_shared(*target, triple);
+return std::make_shared(*target, triple);
 
-  return instance;
+  return lldb::TypeSystemSP();
 }
 
 LanguageSet TypeSystemClang::GetSupportedLanguagesForTypes() {


[Lldb-commits] [lldb] [lldb][ExpressionParser][NFCI] Log pointers as hex (PR #91989)

2024-05-13 Thread Michael Buch via lldb-commits

https://github.com/Michael137 closed 
https://github.com/llvm/llvm-project/pull/91989
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 276c0bd - [lldb][ExpressionParser][NFCI] Log pointers as hex (#91989)

2024-05-13 Thread via lldb-commits

Author: Michael Buch
Date: 2024-05-13T18:47:39+01:00
New Revision: 276c0bd4b386cc6b9d91e5e44ca7b053c11f13b5

URL: 
https://github.com/llvm/llvm-project/commit/276c0bd4b386cc6b9d91e5e44ca7b053c11f13b5
DIFF: 
https://github.com/llvm/llvm-project/commit/276c0bd4b386cc6b9d91e5e44ca7b053c11f13b5.diff

LOG: [lldb][ExpressionParser][NFCI] Log pointers as hex (#91989)

This ensures that we log pointers as lower-case hex. E.g., instead of:
```
 LayoutRecordType on (ASTContext*)0x00010E78D600 'scratch ASTContext' for 
(RecordDecl*)0x00010E797
```
we now log:
```
 LayoutRecordType on (ASTContext*)0x00010e78d600 'scratch ASTContext' for 
(RecordDecl*)0x00010e797
```

Which is consistent with how the AST dump gets emitted into the log.
This makes it easier to correlate pointers we log from LLDB and pointers
that are part of any AST dumps in the same `expr` log.

Added: 


Modified: 
lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp

Removed: 




diff  --git a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp 
b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
index 30b50df79da90..44071d1ea71c7 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
@@ -313,8 +313,8 @@ CompilerType ClangASTImporter::DeportType(TypeSystemClang 
,
 return {};
 
   LLDB_LOG(log,
-   "[ClangASTImporter] DeportType called on ({0}Type*){1} "
-   "from (ASTContext*){2} to (ASTContext*){3}",
+   "[ClangASTImporter] DeportType called on ({0}Type*){1:x} "
+   "from (ASTContext*){2:x} to (ASTContext*){3:x}",
src_type.GetTypeName(), src_type.GetOpaqueQualType(),
_ctxt->getASTContext(), ());
 
@@ -334,8 +334,8 @@ clang::Decl *ClangASTImporter::DeportDecl(clang::ASTContext 
*dst_ctx,
 
   clang::ASTContext *src_ctx = >getASTContext();
   LLDB_LOG(log,
-   "[ClangASTImporter] DeportDecl called on ({0}Decl*){1} from "
-   "(ASTContext*){2} to (ASTContext*){3}",
+   "[ClangASTImporter] DeportDecl called on ({0}Decl*){1:x} from "
+   "(ASTContext*){2:x} to (ASTContext*){3:x}",
decl->getDeclKindName(), decl, src_ctx, dst_ctx);
 
   DeclContextOverride decl_context_override;
@@ -352,8 +352,8 @@ clang::Decl *ClangASTImporter::DeportDecl(clang::ASTContext 
*dst_ctx,
 return nullptr;
 
   LLDB_LOG(log,
-   "[ClangASTImporter] DeportDecl deported ({0}Decl*){1} to "
-   "({2}Decl*){3}",
+   "[ClangASTImporter] DeportDecl deported ({0}Decl*){1:x} to "
+   "({2}Decl*){3:x}",
decl->getDeclKindName(), decl, result->getDeclKindName(), result);
 
   return result;
@@ -637,8 +637,8 @@ bool ClangASTImporter::importRecordLayoutFromOrigin(
 
   clang::ASTContext _ctx = record->getASTContext();
   LLDB_LOG(log,
-   "LayoutRecordType on (ASTContext*){0} '{1}' for (RecordDecl*)"
-   "{2} [name = '{3}']",
+   "LayoutRecordType on (ASTContext*){0:x} '{1}' for (RecordDecl*)"
+   "{2:x} [name = '{3}']",
_ctx,
TypeSystemClang::GetASTContext(_ctx)->getDisplayName(), record,
record->getName());
@@ -703,7 +703,7 @@ bool ClangASTImporter::importRecordLayoutFromOrigin(
 
   if (log) {
 LLDB_LOG(log, "LRT returned:");
-LLDB_LOG(log, "LRT   Original = (RecordDecl*){0}",
+LLDB_LOG(log, "LRT   Original = (RecordDecl*){0:x}",
  static_cast(origin_record.decl));
 LLDB_LOG(log, "LRT   Size = {0}", size);
 LLDB_LOG(log, "LRT   Alignment = {0}", alignment);
@@ -711,11 +711,11 @@ bool ClangASTImporter::importRecordLayoutFromOrigin(
 for (RecordDecl::field_iterator fi = record->field_begin(),
 fe = record->field_end();
  fi != fe; ++fi) {
-  LLDB_LOG(log,
-   "LRT (FieldDecl*){0}, Name = '{1}', Type = '{2}', Offset = "
-   "{3} bits",
-   *fi, fi->getName(), fi->getType().getAsString(),
-   field_offsets[*fi]);
+  LLDB_LOG(
+  log,
+  "LRT (FieldDecl*){0:x}, Name = '{1}', Type = '{2}', Offset = "
+  "{3} bits",
+  *fi, fi->getName(), fi->getType().getAsString(), field_offsets[*fi]);
 }
 DeclFromParser parser_cxx_record =
 DynCast(parser_record);
@@ -734,7 +734,7 @@ bool ClangASTImporter::importRecordLayoutFromOrigin(
 DynCast(base_record);
 
 LLDB_LOG(log,
- "LRT {0}(CXXRecordDecl*){1}, Name = '{2}', Offset = "
+ "LRT {0}(CXXRecordDecl*){1:x}, Name = '{2}', Offset = "
  "{3} chars",
  (is_virtual ? "Virtual " : ""), base_cxx_record.decl,
  

[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits


@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 

jeffreytan81 wrote:

This is not used.

https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits


@@ -743,9 +743,28 @@ DebuggerSP 
Debugger::CreateInstance(lldb::LogOutputCallback log_callback,
 }
 
 void Debugger::HandleDestroyCallback() {
-  if (m_destroy_callback) {
-m_destroy_callback(GetID(), m_destroy_callback_baton);
-m_destroy_callback = nullptr;
+  std::lock_guard guard(m_destroy_callback_mutex);
+  const lldb::user_id_t user_id = GetID();
+  // This loop handles the case where callbacks are added/removed by existing
+  // callbacks during the loop, as the following:
+  // - Added callbacks will always be invoked.
+  // - Removed callbacks will never be invoked. That is *unless* the loop
+  //   happens to invoke the said callbacks first, before they get removed.
+  //   In this case, the callbacks gets invoked, and the removal return false.
+  //
+  // In the removal case, because the order of the container is random, it's
+  // wise to not depend on the order and instead implement logic inside the
+  // callbacks to decide if their work should be skipped.
+  while (m_destroy_callback_and_baton.size()) {
+auto iter = m_destroy_callback_and_baton.begin();
+const lldb::destroy_callback_token_t  = iter->first;
+const lldb_private::DebuggerDestroyCallback  = iter->second.first;
+void *const  = iter->second.second;
+callback(user_id, baton);
+// Using `token` to erase, because elements may have been added/removed, 
and
+// that will cause error "invalid iterator access!" if `iter` is used
+// instead.
+m_destroy_callback_and_baton.erase(token);

jeffreytan81 wrote:

Any reason we remove after calling the callback?

https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits


@@ -161,3 +161,122 @@ def foo(dbg_id):
 original_dbg_id = self.dbg.GetID()
 self.dbg.Destroy(self.dbg)
 self.assertEqual(destroy_dbg_id, original_dbg_id)
+
+def test_AddDestroyCallback(self):
+original_dbg_id = self.dbg.GetID()
+called = []
+
+def foo(dbg_id):
+# Need nonlocal to modify closure variable.
+nonlocal called
+called += [('foo', dbg_id)]
+
+def bar(dbg_id):
+# Need nonlocal to modify closure variable.
+nonlocal called
+called += [('bar', dbg_id)]
+
+token_foo = self.dbg.AddDestroyCallback(foo)
+token_bar = self.dbg.AddDestroyCallback(bar)
+self.dbg.Destroy(self.dbg)
+
+# Should call both `foo()` and `bar()`. Order is undermined because
+# of the `unordered_map` in the implementation.
+self.assertTrue(('foo', original_dbg_id) in called)
+self.assertTrue(('bar', original_dbg_id) in called)

jeffreytan81 wrote:

Use `self.assertIn()`

https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits


@@ -194,7 +194,7 @@ class LLDB_API SBDebugger {
   lldb::SBCommandInterpreter GetCommandInterpreter();
 
   void HandleCommand(const char *command);
-  
+

jeffreytan81 wrote:

Remove unnecessary format change

https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits

https://github.com/jeffreytan81 edited 
https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits


@@ -743,9 +743,28 @@ DebuggerSP 
Debugger::CreateInstance(lldb::LogOutputCallback log_callback,
 }
 
 void Debugger::HandleDestroyCallback() {
-  if (m_destroy_callback) {
-m_destroy_callback(GetID(), m_destroy_callback_baton);
-m_destroy_callback = nullptr;
+  std::lock_guard guard(m_destroy_callback_mutex);
+  const lldb::user_id_t user_id = GetID();
+  // This loop handles the case where callbacks are added/removed by existing
+  // callbacks during the loop, as the following:
+  // - Added callbacks will always be invoked.
+  // - Removed callbacks will never be invoked. That is *unless* the loop
+  //   happens to invoke the said callbacks first, before they get removed.
+  //   In this case, the callbacks gets invoked, and the removal return false.
+  //
+  // In the removal case, because the order of the container is random, it's
+  // wise to not depend on the order and instead implement logic inside the
+  // callbacks to decide if their work should be skipped.
+  while (m_destroy_callback_and_baton.size()) {

jeffreytan81 wrote:

Use `m_destroy_callback_and_baton.empty()`

https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits


@@ -1689,35 +1689,56 @@ void 
SBDebugger::SetLoggingCallback(lldb::LogOutputCallback log_callback,
 void SBDebugger::SetDestroyCallback(
 lldb::SBDebuggerDestroyCallback destroy_callback, void *baton) {
   LLDB_INSTRUMENT_VA(this, destroy_callback, baton);
+
   if (m_opaque_sp) {
-return m_opaque_sp->SetDestroyCallback(
-destroy_callback, baton);
+m_opaque_sp->SetDestroyCallback(destroy_callback, baton);
   }
 }
 
+lldb::destroy_callback_token_t
+SBDebugger::AddDestroyCallback(lldb::SBDebuggerDestroyCallback 
destroy_callback,
+   void *baton) {
+  LLDB_INSTRUMENT_VA(this, destroy_callback, baton);
+
+  if (m_opaque_sp) {
+return m_opaque_sp->AddDestroyCallback(destroy_callback, baton);
+  }
+  return LLDB_INVALID_DESTROY_CALLBACK_TOKEN;
+}
+
+bool SBDebugger::RemoveDestroyCallback(lldb::destroy_callback_token_t token) {
+  LLDB_INSTRUMENT_VA(this, token);
+
+  if (m_opaque_sp) {
+return m_opaque_sp->RemoveDestroyCallback(token);
+  }
+  return false;
+}
+
 SBTrace
 SBDebugger::LoadTraceFromFile(SBError ,
   const SBFileSpec _description_file) {
   LLDB_INSTRUMENT_VA(this, error, trace_description_file);
+
   return SBTrace::LoadTraceFromFile(error, *this, trace_description_file);
 }
 
 void SBDebugger::RequestInterrupt() {
   LLDB_INSTRUMENT_VA(this);
-  
+
   if (m_opaque_sp)
-m_opaque_sp->RequestInterrupt();  
+m_opaque_sp->RequestInterrupt();
 }
 void SBDebugger::CancelInterruptRequest()  {
   LLDB_INSTRUMENT_VA(this);
-  
+
   if (m_opaque_sp)
-m_opaque_sp->CancelInterruptRequest();  
+m_opaque_sp->CancelInterruptRequest();
 }
 
 bool SBDebugger::InterruptRequested()   {
   LLDB_INSTRUMENT_VA(this);
-  
+
   if (m_opaque_sp)

jeffreytan81 wrote:

Undo all these unnecessary changes.

https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits


@@ -743,9 +743,28 @@ DebuggerSP 
Debugger::CreateInstance(lldb::LogOutputCallback log_callback,
 }
 
 void Debugger::HandleDestroyCallback() {
-  if (m_destroy_callback) {
-m_destroy_callback(GetID(), m_destroy_callback_baton);
-m_destroy_callback = nullptr;
+  std::lock_guard guard(m_destroy_callback_mutex);
+  const lldb::user_id_t user_id = GetID();
+  // This loop handles the case where callbacks are added/removed by existing
+  // callbacks during the loop, as the following:
+  // - Added callbacks will always be invoked.
+  // - Removed callbacks will never be invoked. That is *unless* the loop
+  //   happens to invoke the said callbacks first, before they get removed.
+  //   In this case, the callbacks gets invoked, and the removal return false.
+  //
+  // In the removal case, because the order of the container is random, it's
+  // wise to not depend on the order and instead implement logic inside the
+  // callbacks to decide if their work should be skipped.
+  while (m_destroy_callback_and_baton.size()) {
+auto iter = m_destroy_callback_and_baton.begin();
+const lldb::destroy_callback_token_t  = iter->first;
+const lldb_private::DebuggerDestroyCallback  = iter->second.first;
+void *const  = iter->second.second;

jeffreytan81 wrote:

I do not think you need to take reference to them. Copy by value is good to 
avoid indirection.

https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

2024-05-13 Thread via lldb-commits

https://github.com/jeffreytan81 requested changes to this pull request.


https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB/Coredump] Only take the Pthread from start start to the stackpointer + red_zone (PR #92002)

2024-05-13 Thread Jacob Lalonde via lldb-commits


@@ -6410,12 +6410,20 @@ GetCoreFileSaveRangesStackOnly(Process ,
 if (!reg_ctx_sp)
   continue;
 const addr_t sp = reg_ctx_sp->GetSP();
+const size_t red_zone = process.GetABI()->GetRedZoneSize();

Jlalond wrote:

Correct, but on systems where it would be greater than 0, we ensure we capture 
it for the memory dump as well.

https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


  1   2   3   >