This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Several regressions and we branch soon.
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Patrick Palka <patrick at parcs dot ath dot cx>
- Cc: Doug Evans <dje at google dot com>, Keith Seitz <keiths at redhat dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Wed, 24 Jun 2015 12:55:04 +0100
- Subject: Re: Several regressions and we branch soon.
- Authentication-results: sourceware.org; auth=none
- References: <CADPb22SYnN52pqR+1UtR_Vr-1Yxzmx=OyMgnCD-OMcCL1GwAYg at mail dot gmail dot com> <CA+C-WL_uZdNj29-6u4MnqH-8zQt9Q20fzUb6b9nWHKJPCstY9A at mail dot gmail dot com> <CADPb22Rg2FySdxWo9VKb5WApPh-wdf946po9UXX-+kQ99bULug at mail dot gmail dot com> <5589BECB dot 7090200 at redhat dot com> <CADPb22RbcoyxPwwTTQCjSTdexN-D-gfWPd6doF2KbcMm074XyA at mail dot gmail dot com> <alpine dot DEB dot 2 dot 20 dot 8 dot 1506231742590 dot 4322 at idea>
Patrick Palka <patrick@parcs.ath.cx> writes:
> The problem here seems to be that the "show" function corresponding to
> the "mpx bound" command calls error("Intel(R) Memory Protection
> Extensions not supported on this target."); which throws an exception
> that causes the entire "info set"/"show" loop to exit early. Should
Yes, I think your analysis is correct.
> "show foo" ever throw an exception? Should the "info set"/"show" loop
> expect an exception to be thrown from a show function?
IMO, "show foo" shouldn't throw an exception.
>
> This diff fixes the default.exp FAILs as far as I can tell:
>
Thanks for the fix, but I feel that the original code has some drawbacks,
> diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
> index 42d0346..d11efa1 100644
> --- a/gdb/i386-tdep.c
> +++ b/gdb/i386-tdep.c
> @@ -8777,11 +8777,17 @@ i386_mpx_info_bounds (char *args, int from_tty)
> struct type *data_ptr_type = builtin_type (gdbarch)->builtin_data_ptr;
>
> if (!i386_mpx_enabled ())
> - error (_("Intel(R) Memory Protection Extensions not\
> - supported on this target."));
> + {
> + printf_unfiltered (_("Intel(R) Memory Protection Extensions not "
> + "supported on this target.\n"));
> + return;
> + }
>
> if (args == NULL)
> - error (_("Address of pointer variable expected."));
> + {
> + printf_unfiltered (_("Address of pointer variable expected.\n"));
> + return;
> + }
>
> addr = parse_and_eval_address (args);
It is odd that command "info mpx bounds" requires an argument, which is
an address. The set/show command pair works in a way that command set
modify or update some state of GDB, and command info just display the
state of GDB. That is to say, "set mpx bounds ADDRESS" should set
address, which is stored somewhere in GDB (in a global variable or a
per-inferior variable), and "info mpx bounds" shows the current state or
setting in GDB, no argument is needed.
If this is a right direction, I can give a patch.
b.t.w, is it a good (or bad) idea to register this command if mpx
is supported on the target?
--
Yao (éå)