Type of feature request
Additional API
Misc
No response
Summary Description
I wrote a library that works as an abstraction layer for GDB and LLDB to write plugins/scripts that work on both debuggers by writing only debugger-agnostic code.
But I realized that reimplementing an entire debugger's wrapper like GEF or pwndbg would be a huge task that I'm not ready to achieve alone 😅
Therefore, I would like to make GEF debugger agnostic, so that we could use GEF on LLDB, and plugins using only GEF as a library would then also work on LLDB.
This would also mean that we would still rely on GDB/LLDB for testing debugger dependant code, but we could create a third type of debugger TEST that would enable us to test debugger-agnostic code by mocking the debugger's functions. I think it would make the testing lighter if that's something you are interested in.
Implementation idea/suggestion
I think the easiest solution would be to use the library I wrote as a dependency and adapt GEF's code to use this lib instead of GDB API.
Sadly, I think this architecture would be harder to maintain, and I'm not a fan of having dependencies in GEF's core codebase.
Therefore, I think we could create a field in GEF that specifies which debugger is in use, and adapt gdb's dependant code to use the correct API according to which debugger is currently in use. This would also mean that GDB-dependant code would not change (so we would probably not break anything).
We could also create a field in plugins to specify what are the supported debuggers so that when the plugin uses debugger dependant code it would not fail if running on another debugger. If this field does not exist, we would assume that the plugin is only available on GDB to ensure backward compatibility with plugins that were not updated.
Existing alternatives?
The only alternative I know to port a GEF-like project on LLDB is LLEF, but this is still a pretty minimalist project with few features.
I don't know any project that provides a debugger-agnostic API to interact with the debugger.
Additional information
I think the priority is to make tests available on LLDB to track our progress and see where we missed debugger-dependent code.
Then we could adapt GEF's core codebase, and finally we could work on gef-extras to adapt plugins to this new architecture.
Type of feature request
Additional API
Misc
No response
Summary Description
I wrote a library that works as an abstraction layer for GDB and LLDB to write plugins/scripts that work on both debuggers by writing only debugger-agnostic code.
But I realized that reimplementing an entire debugger's wrapper like GEF or pwndbg would be a huge task that I'm not ready to achieve alone 😅
Therefore, I would like to make GEF debugger agnostic, so that we could use GEF on LLDB, and plugins using only GEF as a library would then also work on LLDB.
This would also mean that we would still rely on GDB/LLDB for testing debugger dependant code, but we could create a third type of debugger
TESTthat would enable us to test debugger-agnostic code by mocking the debugger's functions. I think it would make the testing lighter if that's something you are interested in.Implementation idea/suggestion
I think the easiest solution would be to use the library I wrote as a dependency and adapt GEF's code to use this lib instead of GDB API.
Sadly, I think this architecture would be harder to maintain, and I'm not a fan of having dependencies in GEF's core codebase.
Therefore, I think we could create a field in GEF that specifies which debugger is in use, and adapt gdb's dependant code to use the correct API according to which debugger is currently in use. This would also mean that GDB-dependant code would not change (so we would probably not break anything).
We could also create a field in plugins to specify what are the supported debuggers so that when the plugin uses debugger dependant code it would not fail if running on another debugger. If this field does not exist, we would assume that the plugin is only available on GDB to ensure backward compatibility with plugins that were not updated.
Existing alternatives?
The only alternative I know to port a GEF-like project on LLDB is LLEF, but this is still a pretty minimalist project with few features.
I don't know any project that provides a debugger-agnostic API to interact with the debugger.
Additional information
I think the priority is to make tests available on LLDB to track our progress and see where we missed debugger-dependent code.
Then we could adapt GEF's core codebase, and finally we could work on gef-extras to adapt plugins to this new architecture.