So, only self-hosted debugging on x86_64 Linux. A good start.
Now make it work for other common CPUs (aarch64, RISC-V).
Make it work for other OSes (FreeBSD has ptrace, for example).
Make sure it handles signal and thread trampolines, calls through the VDSO, and handwritten assembler that does not have function prologues. Handle C++ constructors and destructors of objects in static storage running before/after main().
Have it intercept signals. Have it follow the child or the parent after forking. Have it handle multiple threads.
Make it work with coredumps.
Make it work on core dumps from a foreign CPU architecture (big-endian PowerPC, for example).
Make it work with debug symbols in separate files from the executable.
Make it work with binaries compiled from languages other than C.
You're going to be busy for the next 20 years or so.
Yeah, I don't think so. It's x86_64 only, and C only too. Some points from your list make sense now, but most of it is simply not part of Spray's scope, and never has been ...
The point the parent commenter is trying to make is that building a general purpose C debugger is not some kind of trivial exercise that can be shipped in 6 months, and claiming to have done so is disingenuous and pompous.
The parent commenter doesn't need to piss on a 17 year old for sharing their work and progress. You could also take a moment to step back and reflect on this.
> building a general purpose C debugger is not some kind of trivial exercise
Yes
> claiming to have done so is disingenuous and pompous
Nobody has claimed to do so in this situation. You are inventing conflict. Also I don't think bregma intended to be this targeting or accusatory, why are you speaking for them?
I just spent ~1.5 years of my life on various aspects of debuginfos and that even just for profiling where I only need line/column information. So I feel this comment through and through.
This is precisely what we are trying to do at Rizin[1][2]. Though the primary goal of the tool/framework is static analysis. All that portability across OSes, their versions, platforms and architectures, etc is definitely hard. If anyone is interested in these subjects, all contributions are welcome. For example, check out our "RzDebug" label, marking debugging issues[3].
Now make it work for other common CPUs (aarch64, RISC-V).
Make it work for other OSes (FreeBSD has ptrace, for example).
Make sure it handles signal and thread trampolines, calls through the VDSO, and handwritten assembler that does not have function prologues. Handle C++ constructors and destructors of objects in static storage running before/after main().
Have it intercept signals. Have it follow the child or the parent after forking. Have it handle multiple threads.
Make it work with coredumps.
Make it work on core dumps from a foreign CPU architecture (big-endian PowerPC, for example).
Make it work with debug symbols in separate files from the executable.
Make it work with binaries compiled from languages other than C.
You're going to be busy for the next 20 years or so.