With the recently integrated (gdb) set debuginfod* changes, things look different and better in some ways. Some suggestions for (re)consideration: 1. defaulting to "set debuginfod off" for batch usage is kind of unfortunate. Programs that use gdb under the covers to do backtracing or whatever now would start to require an extra gdb command option just to work as well as gdb 10 did. I -think- that batch usage of gdb is LESS latency / comfort sensitive, so maybe the default should be "on" for them rather than "off". 2. displaying "Downloading -0.00 MB separate debug info for ..." is confusing. Maybe the files came down too quickly, and the client didn't pass a late enough progress callback. (If so, perhaps we could fix that on the debuginfod side, but I think the code there is good. GDB should get a notification for the last download completion packet.) It'd be better to omit the number, or perhaps replace it from an actual fstat st_size kind of number if necessary. 3. having "set debuginfod ask" be the default is fine for interactive users - that was the whole point of the patchset. But answering "y" is purely transient, as opposed to one-time. Could gdb append a setting to its own .gdbinit file so that the "y" sticks?
(In reply to Frank Ch. Eigler from comment #0) > With the recently integrated (gdb) set debuginfod* changes, things look > different and better in some ways. Some suggestions for (re)consideration: > > 1. defaulting to "set debuginfod off" for batch usage is kind of > unfortunate. Programs that use gdb under the covers to do backtracing or > whatever now would start to require an extra gdb command option just to work > as well as gdb 10 did. I -think- that batch usage of gdb is LESS latency / > comfort sensitive, so maybe the default should be "on" for them rather than > "off". If I understood correctly the original request, defaulting to "no" was for privacy reasons, making sure to get the user's opt-in before the tool contacts an external server. If so, this would be important regardless of whether the usage is interactive or not. cessary. > 3. having "set debuginfod ask" be the default is fine for interactive users > - that was the whole point of the patchset. But answering "y" is purely > transient, as opposed to one-time. Could gdb append a setting to its own > .gdbinit file so that the "y" sticks? Is the message telling the user to add the comment to their .gdbinit not enough?
(In reply to Frank Ch. Eigler from comment #0) > With the recently integrated (gdb) set debuginfod* changes, things look > different and better in some ways. Some suggestions for (re)consideration: > > 1. defaulting to "set debuginfod off" for batch usage is kind of > unfortunate. Programs that use gdb under the covers to do backtracing or > whatever now would start to require an extra gdb command option just to work > as well as gdb 10 did. I -think- that batch usage of gdb is LESS latency / > comfort sensitive, so maybe the default should be "on" for them rather than > "off". We introduced a first-use notice and made it interactive because we wanted to make sure users were sufficiently informed that they'd be relying on an external service. This was done at the expense of adding an extra step (responding to a prompt) to enable debuginfod. Does this rational also apply to batch usage? If we valued informed consent enough to make the interactive prompt in the first place then I think it's fair that enabling debuginfod during batch usage also requires an additional step to ensure consent. Personally I'd be ok with debuginfod enabling by default but seemingly enough folks have reasonable privacy concerns around this. Ex. a tool quietly downloading executables in the background via gdb by default. > 2. displaying "Downloading -0.00 MB separate debug info for ..." is > confusing. Maybe the files came down too quickly, and the client didn't > pass a late enough progress callback. (If so, perhaps we could fix that on > the debuginfod side, but I think the code there is good. GDB should get a > notification for the last download completion packet.) It'd be better to > omit the number, or perhaps replace it from an actual fstat st_size kind of > number if necessary. Yes "-0.00 MB" seems to coincide with small downloads. I'll try to fix this on the gdb side. > 3. having "set debuginfod ask" be the default is fine for interactive users > - that was the whole point of the patchset. But answering "y" is purely > transient, as opposed to one-time. Could gdb append a setting to its own > .gdbinit file so that the "y" sticks? I'm fine with the current default but I don't really have a good sense of what the average user wants in this case. If the response to this prompt persists across sessions and debuginfod was disabled it might be useful to have a once-per-session reminder that debuginfod is available. Something like: Debuginfod is currently disabled. Debuginfod can be enabled using "set debuginfod enabled on"
(In reply to Simon Marchi from comment #1) > (In reply to Frank Ch. Eigler from comment #0) > > With the recently integrated (gdb) set debuginfod* changes, things look > > different and better in some ways. Some suggestions for (re)consideration: > > > > 1. defaulting to "set debuginfod off" for batch usage is kind of > > unfortunate. [...] > > If I understood correctly the original request, defaulting to "no" was for > privacy reasons, making sure to get the user's opt-in before the tool > contacts an external server. If so, this would be important regardless of > whether the usage is interactive or not. The angle I'm focusing on here is that gdb is used by non-human-users to do batch work. I -suspect- that much? most? gdb -batch usage might in fact be performed by automated tooling rather than humans. (Rather than privacy, the motivation for this was more security, in case a user might be concerned about downloading corrupted data. There is hardly any private information sent to a server. Not sure this matters for this topic.) > Is the message telling the user to add the comment to their .gdbinit not > enough? IMHO it'd be better if gdb were to do that. Is there any precedent for persistent settings like this?
For an example of gdb batch mode use by tools: abrt. They run gdb to generate backtraces from crashed program coredumps. There appears to be no way for a user to interact with the prompt, so no obvious clue that they should even consider adding something to their .gdbinit.