This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 00/11] Cleanup deprecated_*_hooks in defs.h
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Philipp Rudo <prudo at linux dot vnet dot ibm dot com>
- Cc: Simon Marchi <simon dot marchi at polymtl dot ca>, Tom Tromey <tom at tromey dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Andreas Arnez <arnez at linux dot vnet dot ibm dot com>, Patrick Monnerat <Patrick dot Monnerat at datasphere dot ch>, Keith Seitz <keiths at redhat dot com>
- Date: Wed, 1 Mar 2017 22:17:37 +0000
- Subject: Re: [PATCH 00/11] Cleanup deprecated_*_hooks in defs.h
- Authentication-results: sourceware.org; auth=none
- References: <20170228145016.22604-1-prudo@linux.vnet.ibm.com> <87innuwd0x.fsf@tromey.com> <51267a8c31e5193bdc3a3e9d7c38be48@polymtl.ca> <20170301101132.12dfd0b2@ThinkPad>
On 17-03-01 10:11:32, Philipp Rudo wrote:
> >
> > However, I think we are in a weird position where we have some
> > deprecated features used by a program that we don't want to break,
> > but that will most likely not change to stop using these features.
> > If we want to exit that endless loop some day, I guess Insight should
> > be converted to use MI, like other frontends.
>
> This really is a tricky situation. I think converting to MI will be
> the best for insight. Although I fear that this will be a bigger
> task. What I found out when I looked at deprecated_query_hook (still
> used in MI interpreter) this is not so simple as setting this hook only
> changes GDBs behavior on certain conditions. Such that just checking
> for "interp->is_mi_like ()" would not help. I fear for insight this
> will be similar.
>
> @Patrick: Can you estimate how much work convering to MI would be?
Why is it MI? MI is for inter-process communication between front-end,
such as Emacs and Eclipse, and GDB. The way Insight using GDB doesn't
fall in this model. It just build with GDB source with gdbtk. There is
no inter-process communication. Observer is a better choice.
Andrew Cagney introduced observers and the deprecated hooks in 2004.
https://sourceware.org/ml/gdb-patches/2004-04/msg00271.html
Some of hooks were replaced by observers, but there are still some
leftovers, as we see today. To be clear, I don't suggest we need to
convert these hooks to observers now.
> From https://sourceware.org/ml/gdb-patches/2017-02/msg00730.html
> Keith> However, I don't think this patch should be dismissed solely
> Keith> because Insight still uses them. [Insight was "kicked out" of
> Keith> the official GDB repository several years ago.]
> Keith>
> Keith> Instead, I would like to ask maintainers to consider
> Keith> that the "true" deprecation of these hooks be phased in over
> Keith> a release or three to give time to either replace
> Keith> them or assess how much time may be needed to properly replace
> Keith> these hooks.
>
> Considering that insight still uses the hooks waiting for N releases so
> they have time to adept sounds fair.
>
> By the way, is there something like a deprecation policy for GDB? Or a
> place where deprecated features are collected? If not a policy like
>
> "When GDB deprecates features they are prefixed with 'deprecated_' and
> deleted N releases after deprecation. Deprecated features and their
> time of deletion are collected in the Wiki/NEWS/FIXME."
Insight is a special case, because GDB isn't compiled with/for other
programs, so the interfaces are CLI and MI. AFAIK, we have
deprecated_cmd_warning. We deprecated some hooks in 2004, but we
didn't provide alternatives.
>
> might be good. What would that mean for code in GDB which still uses
> those features? As mentioned before MI also uses two of those
> deprecated hooks. Furthermore other parts of GDB also have deprecated
> features...
>
If these deprecated_ functions are not used by Insight, we are free to
remove them.
> frame.h:740:extern int deprecated_frame_register_read (struct frame_info *frame, int regnum,
> frame.h:830:extern struct frame_info *deprecated_safe_get_selected_frame (void);
> gdbarch.h:388:extern int gdbarch_deprecated_fp_regnum (struct gdbarch *gdbarch);
> gdbarch.h:389:extern void set_gdbarch_deprecated_fp_regnum (struct gdbarch *gdbarch, int deprecated_fp_regnum);
> gdbarch.h:600:extern CORE_ADDR gdbarch_deprecated_function_start_offset (struct gdbarch *gdbarch);
> gdbarch.h:601:extern void set_gdbarch_deprecated_function_start_offset (struct gdbarch *gdbarch, CORE_ADDR deprecated_function_start_offset);
> gdbarch.h:1745:extern void deprecated_set_gdbarch_data (struct gdbarch *gdbarch,
> gdbcore.h:237:extern void deprecated_add_core_fns (struct core_fns *cf);
We can remove them, no problem.
> target.h:2327:extern void add_deprecated_target_alias (struct target_ops *t, char *alias);
> tracepoint.h:305:extern void (*deprecated_trace_find_hook) (char *arg, int from_tty);
> tracepoint.h:306:extern void (*deprecated_trace_start_stop_hook) (int start, int from_tty);
These two hooks are not used at all.
> value.h:110:extern void deprecated_set_value_type (struct value *value,
> value.h:145:extern int deprecated_value_modifiable (const struct value *value);
> value.h:414:extern enum lval_type *deprecated_value_lval_hack (struct value *);
> value.h:434:extern struct internalvar **deprecated_value_internalvar_hack (struct value *);
> value.h:441:extern struct frame_id *deprecated_value_next_frame_id_hack (struct value *);
> value.h:451:extern int *deprecated_value_regnum_hack (struct value *);
We can remove them too.
--
Yao