Replies: 5 comments
-
I would like to work on this since I already implemented this LLDB support in the library I described. |
Beta Was this translation helpful? Give feedback.
-
This has been a topic of talks for years. At this point I'm not for or against anything, as long as:
I welcome discussion here on this topic, if you have (useful) inputs on the matter and (better) want to take lead on this, feel free to drop a note. |
Beta Was this translation helpful? Give feedback.
-
About the "why" for lldb:
According to me, the main problem is of course the quantity of work required to do such a thing. Still, as I already worked on this same thing as a library, I think that I can see the quantity of work required. It seems like a realistic (long-term) goal to implement this without impacting the current state of gef: same performances and as reliable (on gdb) as it currently is. |
Beta Was this translation helpful? Give feedback.
-
This could also be a good opportunity to add more performance tests, and unit tests for features that look like not that trivial |
Beta Was this translation helpful? Give feedback.
-
I'd like to also add, for most of us OSX hackers, gdb on M chips just does not work by default. If GEF starts supporting LLDB, it's very likely this tool will expand use to all people trying to debug Mac programs, which would be awesome. Even if LLDB support is only tested on Linux, the community (including myself) will likely build on that effort to expand into Mac support. |
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions