On Wed, 17 Mar 2021 01:22:39 GMT, Yasumasa Suenaga <ysuen...@openjdk.org> wrote:
>> If I understand correctly, this is very different than the way we normally >> implement remote debugging support. Normally pages are read in from the >> remote VM process and into the local SA client, where it can then implement >> SA support in much the same way as it normally does. For PStack and PMap, >> you've chosen to instead just execute the commands in the remote debugd >> server, and return the (text) result to the client. It's not clear to me why >> the normal model (of reading in the remote pages and leveraging existing >> PStack and PMAp supprt) can't instead be used so we can keep the remote >> debugging support consistent. How are PStack and PMap different from other >> SA support that does not require remote execution of commands. > >> If I understand correctly, this is very different than the way we normally >> implement remote debugging support. Normally pages are read in from the >> remote VM process and into the local SA client, where it can then implement >> SA support in much the same way as it normally does. For PStack and PMap, >> you've chosen to instead just execute the commands in the remote debugd >> server, and return the (text) result to the client. > > Yes. > >> It's not clear to me why the normal model (of reading in the remote pages >> and leveraging existing PStack and PMAp supprt) can't instead be used so we >> can keep the remote debugging support consistent. How are PStack and PMap >> different from other SA support that does not require remote execution of >> commands. > > SA would set various information when it attaches to debuggee, so it is > difficult to catch up them when remote debugger attached because only debugd > can attach to debuggee directly. > As I said in the description of this PR, both PMap and PStack depend on > CDebugger. CDebugger holds low-level information such as library list and > native thread list. They would be initialized when it attached - it is > startup of debugd, and we cannot get them when we connect to debugd. > > I thought to export CDebugger as RMI object, but it seems to complex. So I > decided to run both pmap and pstack on debugd. Do we have any issues with any other clhsdb commands that rely CDebugger. I haven't looked into the implementation, but I'm suspicious of `thread`, `threads`, `findpc` of an address in the executable, and `findsym`. And speaking of CDebugger, the SA "debugger" hierarchy is too heavily abstracted. I counted about 18 classes and interfaces that have "Debugger" in their name, and some of the interfaces get inherited more than once. I really wonder if it has to be that complex. My first adventure into this mess was for [JDK-8239062](https://bugs.openjdk.java.net/browse/JDK-8239062), a time when I knew close to nothing about SA. Was not fun and I eventually gave up. You might want to have a look at the CR, if not just to add some comments and maybe enlighten me on some things. ------------- PR: https://git.openjdk.java.net/jdk/pull/3027
