I am currently working on a project that involves extending the features on GDB installed in RTEMS. The feature extension I am working on is for GDB to automatically load pretty-printing (Python) scripts upon loading an object file - even for statically linked binaries.
Currently, GDB does this automatically for dynamically linked files, wherein the objfile loading a .so library triggers GDB to automatically load pretty-printer files from the "{prefix}/share/gdb/auto-load" directory. However, this behaviour is not consistent with statically linked binaries.
While looking for fixes for this problem, I came across the solution implemented by Rust in the "rust-gdb" tool, wherein a bash-script is used as a wrapper around GDB to "initialise" it before just running the system's GDB itself. I had a couple of questions about this approach, and was hoping I could find some answers by asking here about them, in order to weigh my options and see how feasible of a solution this might be for RTEMS.
1. How often does Rust need to update/maintain this wrapper? Does it happen with every update to GDB/Rust's debugging setup? 2. If there are updates being made to the wrapper, who is usually the cause (i.e, is it GDB that is causing it, or Rust?) 3. Can we fork the solution implemented in Rust and use it with as little changes as possible? How useful would it be?
I hope any of you can find the time to help me and answer these questions, as knowing insightful details on this implementation would be of immense help to my project.
I haven't looked into the rust-gdb wrapper much, so I don't have any answers to questions regarding it. I thought that there might be another option using a special section known to gdb, the .debug_gdb_scripts section dotdebug_gdb_scripts section (Debugging with GDB) at least I have some (perhaps false) recollection of a library loading pretty printers that way. So perhaps that could be another option.
So there are a couple things good and bad about the .debug_gdb_scripts section.
You can do it by placing the path to the pretty-printers in there, but this has the inherent issue wherein you wouldn't know the full path to the script since every user would realistically install RTEMS at a different $prefix.
You can also do it by placing the entire Python script that you want to execute in there, or inline it - but both of these would require a filename, and GDB checks to see if that file lies in the current working directory (which is the default source path for GDB). You could technically also place the path to a pretty-printing script in there which is under the auto-load safe path, but that brings us back to problem 1.
Of course, the 2nd option would work if we set auto-load safe path to everywhere (/), by invoking set auto-load safe-path /, but that would potentially be a massive security risk to whoever is using it.
The lack of usability of the .debug_gdb_scripts section is why I ventured further for a solution, and stumbled across the wrapper used in rust-gdb, and was wondering how compatible of a solution it would be for RTEMS (ideally, less frequent maintenance is preferred).
We do in fact already emit .debug_gdb_scripts with \x01gdb_load_rust_pretty_printers.py\0" as content, but as @the-m3chanic already said, you still need to take manual action to actually get it loaded by gdb.
There has been one fix for an arg conflict with cgdb, a fix for freebsd. The rest of the changes are just quality-of-life improvements. All fixes for GDB are limited to the actual python pretty printer scripts, which changes a fair bit more frequently. Also in response to changes to the implementation of standard library types.