This is the mail archive of the
mailing list for the GDB project.
Re: [commit] Suggest newer gdbserver if it has no qXfer:exec-file:read
- From: Pedro Alves <palves at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Gary Benson <gbenson at redhat dot com>
- Date: Wed, 6 Apr 2016 16:04:22 +0100
- Subject: Re: [commit] Suggest newer gdbserver if it has no qXfer:exec-file:read
- Authentication-results: sourceware.org; auth=none
- References: <20160319201842 dot GA16540 at host1 dot jankratochvil dot net> <56F13963 dot 9040204 at redhat dot com> <20160322131604 dot GA24312 at host1 dot jankratochvil dot net> <56F14F1E dot 5010606 at redhat dot com> <20160323211547 dot GA17400 at host1 dot jankratochvil dot net> <5703EE91 dot 7040409 at redhat dot com> <20160406143413 dot GA2885 at host1 dot jankratochvil dot net>
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
>> 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
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