[Lldb-commits] [PATCH] D65469: Remove `bugreport` command
Jonas Devlieghere via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Wed Jul 31 10:14:24 PDT 2019
JDevlieghere added a comment.
In D65469#1608653 <https://reviews.llvm.org/D65469#1608653>, @clayborg wrote:
> In D65469#1608631 <https://reviews.llvm.org/D65469#1608631>, @JDevlieghere wrote:
>
> > In D65469#1608278 <https://reviews.llvm.org/D65469#1608278>, @clayborg wrote:
> >
> > > IMHO: we should keep this command and expand its abilities to help report stepping issues, expression issues and more. Why? Getting good bug reports from users is quite hard. Allowing them to type "bugreport step --step-in" or "bugreport step --step-over" would be really nice. Right now I send people a python script that enables logging, dumps the code in and around the source line with disassembly, and creates a zip file with the current object file and optional debug info file (dSYM or external symbol file).
> >
> >
> > What's the benefit of having this instead of having the user generate a reproducer?
>
>
> I am guessing the reproducer wouldn't help us with any of the user files. We often need to see the binaries, or enable some logging when the user repros the bug. Users don't often attach all of the files that are needed, nor do they know what logs to enable and how to attach them. I am not up to date on exactly what reproducers do, but I would guess that they don't save off just the required files or enable any logging and attach logs?
That's exactly what the reproducers do actually. They capture user interaction, the GDB remote packets and any files used by the debugger. They currently don't enable logs, because you can debug LLDB during reproducer replay, but that would be trivial to include as well.
Repository:
rLLDB LLDB
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D65469/new/
https://reviews.llvm.org/D65469
More information about the lldb-commits
mailing list