Support GDB frame filters

[JacquesLucke]

Overview

This adds a new frameFilters option for GDB. When enabled, enable-frame-filters is passed to GDB which will run frame filters before they are passed to the extension.

By default, the option is off to avoid regressions in existing setups. If no issues are found over time, it may make sense to enable them by default. If a user has custom frame filters, it probably makes sense that they should also show up in vscode. It's still always possible to access the full backtrace in the Debug Console.

Motivation

I want to use these filters to simplify debugging when working on Blender. They can greatly simplify the backtraces making them easier to scan in the majority of use-cases. See the example below which shows the original and simplified backtrace. Note that this is still a fairly simple case and the backtrace may become way deeper in some situations.

Before:

After:

Details

For some reason, GDB does not provide the @frame.fullname property for stack frames when frame filters are used. However, in my case @frame.file was provided and contained the absolute path too. So this is now used as a fallback.

Previously, the stack frame name was always function_name@address. However, with frame filters, the address might not always be known. I changed it so that the @address part is omitted when the address is unknown.

[WebFreak001]

thanks for the PR! Just a question about that one kinda very confusing fundamental change

[GitMensch]

@JacquesLucke can you please rebase and add your name entry to the Changelog?

[JacquesLucke]

I updated the patch.

[GitMensch]

@WebFreak001 @JacquesLucke Do you think that we really need to disable frame-filters per default?
GDB will only load frame-filters if it was requested (either on commands setup in launch.json, on debug-console, or from auto-loaded gdb code). Why should we not show the results of these per defaults?
Having this enabled by default would also match what we do with prettyPrinters now (the adjustment in the PR would be minimal, switching the default value in package.json and adjusting the changelog to say ", enabled by default").

... @JacquesLucke and if you update it again, can you please include the single type fix open from https://github.com/WebFreak001/code-debug/pull/434/files#diff-15ecb3c20d4d1bb96e24827f055831bc6dad0a83b404fb8fdc32da1e0d7a831f (yopu know, just because you changed that file as well) and we don't need an extra commit for that change)?

[JacquesLucke]

Do you think that we really need to disable frame-filters per default?

It's probably fine to enable by default, but I only tested with gdb 14.2 and don't know if there are potential problems with other versions. Seems unlikely but hard to say for me. I can turn it on by default

[GitMensch]

per GDB docs the frame-filters and related commands are in since GDB 7.7 and this is our minimal supported version (I think we should add the GDB 7.7+ / LMDB 3.7+ note to the main README...) so that should be fine.
The Changelog entry will allow users to know about it and the new setting allows to provide the old behavior.

so yes, please turn on by default and - as the general review is also done - I'll pull that in

[JacquesLucke]

@GitMensch I did what you suggest. However, in my tests the enable-by-default part does not really work, same for pretty-printing btw. That's because args.frameFilters and args.valuesFormatting are undefined if not explicitly provided. It does not seem to use the default set in package.json.

[GitMensch]

thanks for the update, please squash the commit into one (if I do that your commit is lost - maybe I do that wrong)

[JacquesLucke]

I squashed all my commits into one. I thought Github would let you do this easily as well.

[GitMensch]

You're right, I'll try this merge-squash next time - thanks for your contribution!