On 11/20/21 03:09, Rémi Bernon wrote:
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 ;)
Why fix a working program? "if it works, don't fix it." ;) ;)
Perhaps you meant I wouldn't have worked on it had I known alternatives in the first place. But I didn't know them. So I fixed it. Knowing other ways around now doesn't change something that already happened. :p
Actually the fixes have been hanging around for months now. I could've kept it; Winedbg doesn't really get very frequent updates anyway. But I decided that they are better off on the list. So here we are.
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.
Having both PE and ELF symbols was exactly what I needed. In fact I've wrote a script that does a similar thing. With plain GDB though, I never got "handle SIGxxx pass" to work, so there's that.
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.
The Unix path resolution part only resides in gdbproxy. There's no need to touch non-GDB code at all.
[1] https://www.winehq.org/pipermail/wine-devel/2021-June/189134.html