Re: ping: Re: [patch] Forbid "run" etc. for use_gdb_stub targets

[Doug Evans <dje@google.com>]

On Mon, Dec 5, 2011 at 12:15 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Sun, 04 Dec 2011 03:55:07 +0100, Doug Evans wrote:
>> Poorly chosen names lead to confusion, bugs, and wasted time.
>> [No claim is made that this is news. :-)]
>
> Just $use_gdb_stub is a different form of [target_info exists use_gdb_stub] so
> no matter what the name is IMO it is correct the name is the same.
>
> And one cannot change use_gdb_stub in the board file for board files backward
> compatibility.

I realize that.  grep use_gdb_stub /usr/share/dejagnu/baseboards/*.exp.
ref: http://sourceware.org/ml/gdb-patches/2011-12/msg00048.html

I was suggesting either a layer of abstraction and/or have gdbserver
set something with a more meaningful name, and use the more meaningful
name in contexts where we currently use use_gdb_stubs.

[btw, once gdb_stubs is gone, I think we should also remove (at least
in name) use_gdb_stubs, at least within gdb.  Otherwise we're not
finishing the job of cleaning things up.]

>> Plus, there's no reason why, for example, gdb_start_cmd can't work
>> with target remote and gdbserver.
>
> It does not work with non-extended gdbserver - which has use_gdb_stub == 1.
> Also my change did not change it:
> -    if [target_info exists use_gdb_stub] {
> +    if $use_gdb_stub {
> (gdb) target remote localhost:1234
> Remote debugging using localhost:1234
> [...]
> (gdb) start
> The "remote" target does not support "run".  Try "help target" or "continue".

I realize "target remote" doesn't support "start".
What I meant was there's no reason why gdb_start_cmd couldn't do
something like the following for non-extended-remote gdbserver:

tbreak main
continue

>
> It works with extended gdbserver - which has use_gdb_stub == 0.
>
> I do not see the problem you describe.
>
>
> Thanks,
> Jan
>