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

jarin added a comment. Looking at the code for flushing L1 cache , it appears broken. I am guessing that is the reason for the failure of my patch on the bots. Here is the

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

omjavaid reopened this revision. omjavaid added a comment. This revision is now accepted and ready to land. This patch breaks on TestMemoryCache.py lldb AArch64/Linux. we ll have to revert it untill fixed FAIL: test_memory_cache_dwarf (TestMemoryCache.MemoryCacheTestCase) Test the

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

This revision was automatically updated to reflect the committed changes. Closed by commit rGa53bf9b7c8f1: [lldb-server] jThreadsInfo returns stack memory (authored by jarin, committed by labath). Changed prior to commit: https://reviews.llvm.org/D74398?vs=251714=255316#toc Repository: rG

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

jarin added a comment. Pavel, could you land this for me? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74398/new/ https://reviews.llvm.org/D74398 ___ lldb-commits mailing list

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

jarin added a comment. In D74398#1939372 , @jarin wrote: > In D74398#1935438 , @jasonmolenda > wrote: > > > (and if you're still seeing mystery reads, put a breakpoint on > > ProcessGDBRemote::DoReadMemory and

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

> On Mar 21, 2020, at 10:25 PM, Jason Molenda via Phabricator via lldb-commits > wrote: > > > 0x11232 <+18>: movq %rax, -0x68(%rbp) > 0x11236 <+22>: callq 0x11350 ; > std::__1::vector > >::vector at vector:497 > 0x1123b <+27>: movabsq $0x1, %rax

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

jasonmolenda added a comment. (and if you're still seeing mystery reads, put a breakpoint on ProcessGDBRemote::DoReadMemory and see who is doing it) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74398/new/ https://reviews.llvm.org/D74398

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

jasonmolenda added a comment. In D74398#1935431 , @jasonmolenda wrote: > In D74398#1935043 , @jarin wrote: > > > Regarding the packet savings - there are still things that worry me. > > > > First of all, when lldb

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

jasonmolenda added a comment. In D74398#1935043 , @jarin wrote: > Regarding the packet savings - there are still things that worry me. > > First of all, when lldb CLI stops on a breakpoint, it will first unwind top > of the stack of each thread as part

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

jarin added a comment. Regarding the packet savings - there are still things that worry me. First of all, when lldb CLI stops on a breakpoint, it will first unwind top of the stack of each thread as part of ThreadList::ShouldStop. This sends lots of "x" packets to lldb-server and only then

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

jarin updated this revision to Diff 251714. jarin marked 3 inline comments as done. jarin added a comment. Addressed comments. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74398/new/ https://reviews.llvm.org/D74398 Files:

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

labath accepted this revision. labath added a comment. This revision is now accepted and ready to land. This is great. The new test looks even better than I had hoped for. Thanks for sticking with this. Comment at:

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

jarin updated this revision to Diff 251512. jarin added a comment. Adding a tighter x64 test as suggested by labath@. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74398/new/ https://reviews.llvm.org/D74398 Files:

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

labath added a comment. In D74398#1930021 , @jarin wrote: > In 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

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

jarin added a comment. In 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

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

jarin updated this revision to Diff 251181. jarin marked 5 inline comments as done. jarin added a comment. Addressed reviewer comments in the code, but still have no clue how to write the test. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

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

labath added a comment. 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. I am imagining the

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

jarin updated this revision to Diff 250951. jarin added a comment. - Added a test that checks consistency of thread info's memory chunks with the actual memory. - Using DataExtractor to extract pointers with the right endian-ness and the right size. Repository: rG LLVM Github Monorepo

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

jasonmolenda added a comment. To be honest, I'm thinking of stealing your idea of sending the $fp - $sp memory region for frame 0 in debugserver, at least for the currently selected thread. I might add a check that it's not a huge amount of bytes in case there's a giant buffer or something

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

labath added a comment. BTW, a the `lldb/examples/python/gdbremote.py` script for these kinds of things measurements. It takes a lldb log file produced like so: `log enable gdb-remote packets -T -f /tmp/gdb.log`, and it gives you some statistics about the various packets present there:

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

jarin added a comment. Thank you for the feedback! I am a bit busy with other things ATM, but I should be able to get back to this next week. I should give credit where it's due - Pavel pointed me to the debug-server code and I took the idea from there. We do not always have the frame pointer

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

jasonmolenda added a comment. Nice improvement. debugserver does a similar thing in our jThreadsInfo implementation as well as our ? packet response (T05, etc) where we include the current & caller stack frame, assuming the frame pointer and pc are saved to the stack, 1581545891.235902071 <

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

labath added a comment. > Does this approach sound reasonable? I think this is ok, in principle. It might be nice to include some numbers, like how much this increases the jThreadsInfo packet size vs. how much time or packets does this save us. > How do we test this? I am imagining a

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

jarin created this revision. jarin added a reviewer: labath. jarin added a project: LLDB. Herald added a subscriber: lldb-commits. This patch adds parts of the stack that should be useful for unwinding to the jThreadsInfo reply from lldb-server. We return the top of the stack (12 words), and we