Re: [commit] Suggest newer gdbserver if it has no qXfer:exec-file:read

[Pedro Alves <palves@redhat.com>]

On 04/06/2016 03:34 PM, Jan Kratochvil wrote:
> On Tue, 05 Apr 2016 18:57:53 +0200, Pedro Alves wrote:
>> On 03/23/2016 09:15 PM, Jan Kratochvil wrote:
>>> I still do not see there any hint that a newer FSF gdbserver would also fix the
>>> problem.
>>
>> That's because I don't think it's a good approach.
>>
>> If we followed that direction going forward, we'd end up with:
>>
>>  warning: Remote gdbserver does not support determining executable automatically.
>>  FSF gdbserver version 7.10 or later would support that.
>>  warning: Remote gdbserver does not support foo.
>>  FSF gdbserver version 6.5 or later would support that.
>>  warning: Remote gdbserver does not support bar.
>>  FSF gdbserver version 6.8 or later would support that.
>>
>> Old version numbers shown on purpose -- that's what 7.10
>> will feel like in a couple years.  I think it's not a good
>> idea to show version numbers,
> 

> 
> I never proposed any patch mentioning multiple versions which you claim now to
> be a disadvantage of the patch of mine - that is exactly a straw man argument
> case.

No, it is not.  

I never said _you_ proposed a patch mentioning multiple versions.
I said "If we followed that direction going forward".  Thinking of how a patch
impacts future direction is not a straw man, and must be part of the development
and review process.

The patch mentioning a gdbserver version opens a precedent.  It'd be reasonable
then for other cases to get treated the same way once that direction is set,
and multiple mentions of versions would be what we'd get against some stubs.
Thus, coupled with not all stubs being gdbserver, I think that patch would
set up for the wrong direction, hence the push back.

>> nor am I convinced mentioning
>> gdbserver is a good idea either.  There's bare metal targets, and
>> then there's also other servers like qemu, Valgrind, RR, etc.
>>
>> Sorry for pushing back, but I think warnings should be centered
>> on features, not tools and versions.
> 
> That is technically the right approach but (I think) that does not work for
> laypeople.  But I also think laypeople do not use (at least not directly) GDB
> anyway so trying to make GDB userfriendly is probably a vain attempt
> I sometimes try to do.

Making GDB more user friendly is definitely a good goal, and
much appreciated.

Thanks,
Pedro Alves