RFR: 8366154: Validate thread type requirements in debug commands [v2]

[Kevin Walls]

On Tue, 9 Sep 2025 09:44:42 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> src/hotspot/share/utilities/debug.cpp line 308:
>> 
>>> 306:  public:
>>> 307:   Command(const char* str) : _has_rm(false) {
>>> 308:     if (level++ == 0) {
>> 
>> "level" can recognise concurrent usage, but doesn't protect against it?  The commands still proceed to do their thing, so it doesn't seem right make us skip printing "Executing..." if level was not exactly zero?
>> 
>> (Adding the flush() if there is concurrent might be a good thing, it may help if there is output that could be confused, if that is even possible to achieve...)
>
> My original understanding for the level variable was to handle nested command calls, not concurrent ones.
> 
> For instance, if a command like `find` were to internally call `findm`, printing two "Executing..." messages would be more confusing, as the user executed a single command from gdb.
> 
> On the other hand, is it possible to call these functions from gdb concurrently?

Right, I don't think anybody expects concurrent calls from gdb. 8-)
I didn't see any nested commands either.
I thought it worth mentioning as it is a behaviour change.
I wonder if a command can fail, fault within debugger control, and not decrement the static level?  That might be a reason not to change this, but don't worry too much about proving that, happy either way..  As mentioned earlier the user by this point should be able to cope with whatever happens.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2332868837