On Fri, 3 Sep 2021 05:05:34 GMT, Jakob Cornell <github.com+5642931+jakobcorn...@openjdk.org> wrote:
>> This has been under discussion on and off for the past month or so on >> serviceability-dev, and I think a CSR request is required, so this may be a >> work in progress. >> >> Notes on the patch: >> >> - The `list` command previously marked a line in each listing with `=>`. In >> a bare `list` this is the next line up for execution. Previously when >> requesting a specific location (e.g. `list 5`) the requested line would be >> marked. With the patch applied, `list` will only ever mark the next line up >> for execution. This is consistent with the behavior of GDB and PDB (at >> least). >> - `EOF` is printed when the repeat setting is on and a bare `list` command >> follows a listing containing the last source line. This feature is from >> PDB; it's a somewhat softer message than the one for an explicit `list` >> request that's out of range. >> - I don't speak Chinese or Japanese, so I've omitted localizations for the >> new messages in those locales. However, I updated the help text in both to >> include the new commands, with the descriptions left empty for now. > > Jakob Cornell has updated the pull request incrementally with one additional > commit since the last revision: > > 8271356: Add jtreg tests for command repetition and list auto-advance Great, thanks Chris. Before I write that up I think we need to clarify something with regard to compatibility. In the CSR ticket you mention that behavior is only changed with repeat turned on, but I made a change to how the list marker (`=>`) is used which also affects runs with repeat off [1]. There's some more info in the first bullet point in my initial comment for the PR. So we're going to have to decide whether to include this change. I think it would be confusing for this behavior to be switchable by the `repeat` command, so I propose we either document it in the CSR as an incompatibility or revert the change in the PR. The change is in line with making JDB more consistent with other debuggers, but its appeal is somewhat subjective. Perhaps you can advise as to which option would be better? [1] https://github.com/openjdk/jdk/pull/5290/files#diff-26c2ab70eb013703a8dbf9806cf5677966d91a1fde4b5751c9824d00ed393656R1570 ------------- PR: https://git.openjdk.java.net/jdk/pull/5290
