On 03/10/2013 09:06 AM, Jan Kiszka wrote: >> @@ -2491,6 +2493,10 @@ static int gdb_handle_packet(GDBState *s, const char >> *line_buf) >> break; >> } >> #endif >> + if (strncmp(p, "Attached", 8) == 0) { >> + put_packet(s, gdb_attached ? "1" : "0"); >> + break; >> + } > > This works as expected for system mode, but now inverts the behaviour > for user mode - that's unexpected and not ok. >
OK, I can change the default value for user mode. >> diff --git a/qemu-options.hx b/qemu-options.hx >> index 6f9334a..026d3eb 100644 >> --- a/qemu-options.hx >> +++ b/qemu-options.hx >> @@ -2988,6 +2988,13 @@ property must be set. These objects are placed in the >> '/objects' path. >> ETEXI >> >> +DEF("gdb-not-attached", 0, QEMU_OPTION_gdb_not_attached, >> + "-gdb-not-attached\n" >> + " Do not set Gdb remote server in attached mode.\n" >> + " When exiting debugging session, Gdb will send a >> 'kill'\n" >> + " command instead of a 'detach'.\n", >> + QEMU_ARCH_ALL) >> + > > First of all, why do we need this configurable? In which use cases do > you want attached mode for user emulation or kill mode for system > emulation/virtualization? > It's more convenient for us, we expect QEMU to terminate at the end of debugging session because we do not run big systems/kernels but short test programs. It used to be the default behavior of QEMU, and our test-suites, IDE, developers and users are expecting this. > Then, if you can convince us that such a switch is useful, a new > top-level command line option is still a no-go. We already have -gdb, so > this would have to become an option to it. > Something like: -gdb dev[,attached=on|off] wait for gdb connection on 'dev' This will not fit nicely in the current option because 'dev' is a chardev descriptor. I will have to add 'attached' in the list of chardev opts, which is not correct. Or do some nasty strings manipulation. Maybe this: -gdb-opts attached=on|off We can extend it latter if more options are needed. > In any case, I would suggest to add static attached mode first (enabled > for system, disable for user), revert my patch and then, optionally, > propose an attached mode control. > Mode control is not optional for me. Regards, -- Fabien Chouteau