[Lldb-commits] [PATCH] D74398: [lldb-server] jThreadsInfo returns stack memory

[Jaroslav Sevcik via Phabricator via lldb-commits]

jarin added a comment.

In D74398#1929019 <https://reviews.llvm.org/D74398#1929019>, @labath wrote:

> Thanks. Could you also add the other kind of test (the one inline asm) I mentioned. In an ideal world we'd have a test case for every boundary condition, but we're pretty far from that right now. Even so, one test case like that would be nice.


Pavel, thank you for the careful review! I still do not quite understand how the asm test should look like and where it should live. Are you asking for creating a new directory with a compiled program below and building the machinery to stop at the right place and check the stack? If yes, that sounds like a fairly time-consuming undertaking, and I am afraid I cannot invest much more time into this. Perhaps it is better if we stick this patch only into our lldb branch, this one should be pretty easy for us to rebase.

As for the timings with local lldb on Linux, I see the time for jThreadsInfo of 100 threads with fairly shallow stacks (10 entries or so) taking 20ms locally, as opposed to 4ms before this change. The jThreadsInfo reply size is 80kB, up from 11kB. While this seems excessive, I do not see any extra memory traffic for getting a thread list with the patch,  whereas without this patch we get over 100 roundtrips (each is at least 512 bytes of payload) to display the top of the stack of each thread.

> I am imagining the inferior doing something like:
> 
>   movabsq $0xdead, %rax
>   pushq %rax ; fake pc
>   leaq 0x1000(%rsp), %rbp ; larger than kMaxFrameSize
>   pushq %rbp
>   movq %rsp, %rbp
>   pushq $1 ; fake frame contents
>   pushq $2
>   pushq $3
>   
>   incq %rax
>   push %rax; second fake pc
>   pushq %rbp
>   movq %rsp, %rbp
>   pushq $4 ; fake frame contents
>   pushq $5
>   pushq $6
>   int3
> 
> 
> and then the test would assert that the result contains the entirety of the first fake frame, the bp+pc of the second fake frame, and then would stop due to hitting the kMaxFrameSize boundary.





================
Comment at: lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteThreadsInStopReply.py:373
+        # Read memory chunks from jThreadsInfo.
+        memory_chunks = self.gather_threads_info_memory()
+        # Check the chunks are correct.
----------------
labath wrote:
> Also assert that you have at least one chunk here?
I have asserted that for each thread now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74398/new/

https://reviews.llvm.org/D74398