Re: Another proposal for frontends and queries.

[Hui Zhu <teawater@gmail.com>]

On Thu, Sep 17, 2009 at 02:02, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> ">" == Hui Zhu <teawater@gmail.com> writes:
>
>>> And about the patch I said can handle this issue is "set record query
>>> <on|off>" patch.  I cannot find who don't like this patch.
>
> I don't like it, I think I said that in another thread.
>
> The reason I don't like it is twofold.
>
> First, queries are a general feature of gdb.  They are sprinkled about
> rather liberally.  So, if one causes problems for a front end, then it
> probably represents a general class of problems.  IMO, fixing it in this
> ad hoc way is not a good way to attack a generic problem.
>
> The thought experiment to perform here is to consider generalizing this
> solution to all the queries in gdb.  I think that would result in
> madness: hundreds of "disable this query" settings.
>
> Second, this has the feeling of an "unbreak my gdb" option.  That is,
> setting an option to avoid one particular query says to me that the
> query is probably badly chosen in some way.
>

Sorry I didn't get the mean of "It seems like a strange approach to
me." first time.  Now, I got it.

One day, I try to debug a big program with GDB prec. I don't know why
it get something wrong.  It get bug only after exec a long time.  And
prec will make inferior exec slow (I design dump and skip to make it
fast).  So I enter "record" and "c" command in GDB and go to bed.
In the next morning, I open the LCD and want see what happen.  I found
that GDB is broken by a query.  :(

That is why I like "set rec query off".  It will not be a only switch.
 It will include a lot of switches for each query.  For the advanced
user, he can set each switch and then set rec query off.  Then he can
let GDB unbreak record a long time, and come back to use replay debug
find what happen.

That is why I think "set prec query off" is not bad.

Thanks,
Hui