Community
Participate
Working Groups
I wasn't sure which component to file this against. gdb recently added a "frame filters" feature, which lets Python code modify stack traces in some ways. This feature is exposed to MI, but it requires a special enabling request, and AFAIK Eclipse CDT doesn't yet support it. I think it should. Docs here: http://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Stack-Manipulation.html#GDB_002fMI-Stack-Manipulation See "-enable-frame-filters"
When you say Eclipse CDT should support frame filters, do you mean simply sending -enable-frame-filters to GDB? What would you be able to do that you can't do now? To be useful, the user would need some new UI to define frame filters and display the modified stack traces. It is interesting, but it seems like a big task. If -enable-frame-filters is sent to GDB, we need to make sure to use --no-frame-filters with the -stack-list-* family of commands whenever we want the normal output (e.g. for the default views), to avoid having user-defined frame filters breaking the UI. Does that make sense?
(In reply to comment #1) > When you say Eclipse CDT should support frame filters, do you mean simply > sending -enable-frame-filters to GDB? Yes. > What would you be able to do that you > can't do now? Users could see a filtered view of the frames. For best results (IMO), Eclipse could hide elided frames by default and let users click to see them. The filters need not be editable from Eclipse. We plan to ship some pre-canned filters in the OS; these will be auto-activated the same way that Python pretty-printers are. > If -enable-frame-filters is sent to GDB, we need to make sure to use > --no-frame-filters with the -stack-list-* family of commands whenever we > want the normal output (e.g. for the default views), to avoid having > user-defined frame filters breaking the UI. At least in the case where the user wants the raw view. I think new features should generally be enabled by default.
