[PATCH v4 4/7] winedbg: Buffer and escape output of GDB qXfer commands.

[Rémi Bernon]

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 at 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
-- 
Rémi Bernon <rbernon at codeweavers.com>