I went straight to your Arm instruction disassembly because I’ve been writing one too; did you consider using a data structure like a trie rather than deeply nested conditionals? Any particular reason for one vs the other?
Tangentially related, but recently I've come across a SYM debugging symbols file for a PlayStation game without its matching executable. I had another, more recent executable that wasn't a perfect match for the SYM file, so I couldn't directly make use of it.
I've ended up doing the following to leverage that SYM file:
- build a placeholder ELF program by hand in the shape of the missing executable, but with all sections being NOBITS
- import this placeholder program into Ghidra
- write a Ghidra script to layer the information inside the SYM file on top of the placeholder program
- perform a version tracking session from the placeholder to the real executable, to port the debugging information onto a tangible artifact
My point is, have you thought about the capability to view a debugging data file without having the executable file? This use-case is admittedly a bit fringe, but it can happen with split executable/debug files.
I agree that would be a useful feature but it does seem a bit too fringe.
There's far more demand for a debugger with good rust support.
For that reason I'll likely first try to integrate LLDB into BiTE.
That would in term make it more tied to just loading executables, so the answer would be maybe but it's not a priority.
I was going to say you should do a write-up, then I checked your profile! Very cool. Your debug symbol viewing idea sounds like it'd make for a good standalone tool.
The only thing Itanium related I see in this repository is the Itanium C++ ABI name mangling code. This doesn't mean that the Itanium architecture itself is supported.
I went straight to your Arm instruction disassembly because I’ve been writing one too; did you consider using a data structure like a trie rather than deeply nested conditionals? Any particular reason for one vs the other?
Tangentially related, but recently I've come across a SYM debugging symbols file for a PlayStation game without its matching executable. I had another, more recent executable that wasn't a perfect match for the SYM file, so I couldn't directly make use of it.
I've ended up doing the following to leverage that SYM file:
- build a placeholder ELF program by hand in the shape of the missing executable, but with all sections being NOBITS
- import this placeholder program into Ghidra
- write a Ghidra script to layer the information inside the SYM file on top of the placeholder program
- perform a version tracking session from the placeholder to the real executable, to port the debugging information onto a tangible artifact
My point is, have you thought about the capability to view a debugging data file without having the executable file? This use-case is admittedly a bit fringe, but it can happen with split executable/debug files.
I agree that would be a useful feature but it does seem a bit too fringe. There's far more demand for a debugger with good rust support. For that reason I'll likely first try to integrate LLDB into BiTE. That would in term make it more tied to just loading executables, so the answer would be maybe but it's not a priority.
I was going to say you should do a write-up, then I checked your profile! Very cool. Your debug symbol viewing idea sounds like it'd make for a good standalone tool.
This is a practical tool. Does it support source code searching and function locating?
Cool project! What's the state of DWARF 5 support?
There is DWARF 5 support, it's doesn't yet support .debug_names sections but for the rest it works.
Looks awesome. I hope you could find a way to make LLDB usable with Rust.
Yeah that's the next step probably. It initially had it's own debugger implementation but the scope for that was too great.
The name of the project means dick in french.
was gonna point this out but you beat me to it putain
That sounds like a bonus to me?
i look forward to the optimized version, petite bite.
[dead]
I'm fascinated that this apparently supports Itanium.
The only thing Itanium related I see in this repository is the Itanium C++ ABI name mangling code. This doesn't mean that the Itanium architecture itself is supported.
ah, my mistake. I saw the word and didn't realize the context.