On 11/19/21 18:05, Jinoh Kang wrote:
On 11/20/21 01:42, Rémi Bernon wrote:
On 11/19/21 17:33, Jinoh Kang wrote:
On 11/19/21 23:54, Rémi Bernon wrote:
Hi Jinoh!
A few comments:
On 11/19/21 14:41, Jinoh Kang wrote:
Signed-off-by: Jinoh Kang jinoh.kang.kr@gmail.com
Overall I'd say this one is probably worth splitting. Maybe consider a bit of prior refactoring to use the same "reply_buffer" both for the packet output buffer and the qxfer buffer?
De-duplicating the buffer management code sounds like a good idea.
My intention was to minimise touching existing code and do refactoring in a separate patch serie. Turns out this extra step is unnecessary, I guess.
I think winegdb in general and gdbproxy in particular aren't used very much
Wait, there were any alternatives? Bare GDB was always cumbersome to me, since it never detects all the DLL images automatically.
Maybe I should take a look at MinGW build of gdbserver.
Maybe I shouldn't say anything if you're only interested in fixing it because it doesn't work ;)
But I've personally moved to using GDB directly, with a python script to generate load-symbol-file commands from /proc/self/maps [1], which I find more usable.
and definitely need more love.
Especially since its use is infrequent, test coverage should be what needs most improvement. We can even get free conformance tests if we get rid of all Wine-dependent code from WineDbg (sounds weird, I know).
(The major part of Wine dependence is the Unix path resolution. Removing this would mean that gdbproxy shall implement the file I/O protocol, so that GDB can read files from Windows paths. Sounds like a lot of work, though.)
Although tests could be interesting to have I don't think we want to get rid of the non-GDB code, it still has its use. Making it better could be nice though.
[1] https://www.winehq.org/pipermail/wine-devel/2021-June/189134.html