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

[Jinoh Kang]

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 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 ;)

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

-- 
Sincerely,
Jinoh Kang