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

[Doug Evans <dje at google dot com>]

On Mon, Dec 5, 2011 at 1:27 PM, Doug Evans <dje@google.com> wrote:
> 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

btw ...

I realize gdb.{ada,base}/start.exp uses gdb_start_cmd to actually test
the start command.

There are two independent uses of gdb_start_cmd in the testsuite:
1) test the "start" command
2) runto main without the side-effects of runto_main (delete all breakpoints)

If you want to add a parameter to runto_main, or some such, to skip
the side-effects, that's another way to go.
I don't have strong feelings on actually splitting up gdb_start_cmd into two.