Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Walfred Tedeschi <walfred.tedeschi@intel.com>
To: "Tedeschi, Walfred" <walfred.tedeschi@intel.com>
Cc: "Yao Qi <qiyaoltc@gmail.com>; Patrick Palka
	<patrick@parcs.ath.cx>; Doug Evans <dje@google.com>; Keith Seitz
	<keiths@redhat.com>; gdb-patches" <gdb-patches@sourceware.org>
Subject: Re: Several regressions and we branch soon.
Date: Wed, 01 Jul 2015 09:30:00 -0000	[thread overview]
Message-ID: <5593B32F.6070503@intel.com> (raw)
In-Reply-To: <AC542571535E904D8E8ADAE745D60B1944445D44@IRSMSX104.ger.corp.intel.com>

Hello Yao,

Thank you for your feedback!

See below:

> This command was proposed initially as an standalone like: 
> Set-mpx-bound and show-mpx-bound. Recommendation was to introduce it 
> in the sets and shows, which I have agreed. Also because "set" is also 
> used to set values of variables when used alone. Which is similar to 
> what "set mpx bound" is doing, In this sense it can be considered as 
> the right category to have it, as Joel indicated. About the show, well 
> that is the natural counterpart of the set, right? Also, I agree with 
> Yao patch. I would use a "warning" instead. Initialization of the 
> command can be placed in a different location. I could think of adding 
> them at the validation of the tdesc, i.e. I386_validate_tdesc_p and 
> amd64_validate_tdesc_p. Would you agree with that? Open questions are: 
> 1. Command call. Should they still be called "set mpx bound" / "show 
> mpx bound"
> Command "show mpx bound" expects an argument, which is an address.  Is this argument mandatory?  In other words, can gdb scan bound directory and bound table from inferior memory and print all entries? this would be slow, but "show mpx bound" doesn't need an argument.
Though slow i think it could be done. In case of displaying all entries 
there will be no context for the user. It means he will se a big table 
of numbers.  Therefore we decided to display only for the pointer desired.
In case you guys think that it might be also interesting we could spand 
the command work in that way.
> After I read intel mpx doc and the patch, I have more questions in my mind,
>
>   - if program doesn't set mpx bounds at all, GDB attaches to the program,
>     and set mpx bounds, when GDB detaches from this program, does GDB
>     need to clear these mpx bounds it sets?
In case program does not set bounds GDB will also not able to set 
bounds. Basically idea is to have bounds as variables.
Once user has modified its done.
>   - if program does set mpx bounds too (through mpx instructions or
>     compiler builtins), do we expect GDB to show these mpx bounds too?
No. Same as above.
>   - If program sets mpx bounds through mxp instructions and GDB sets mpx
>     bounds too, does this interfere each other? or program's mxp bounds
>     setting is stored in bnd0-bnd3, but GDB's mpx bound setting is bound
>     directory and bound table, so this doesn't interfere each other?

Yes. Like it happens with variables location dependent variables.
To be able to to set bounds also on registers and tables and make them 
sync we need debug information.
The solution by now is without. In this sense user has to know a bit of 
assembler to know where to set the bounds, for the case it being debugged.

>> 2. Should initialization move to the validation routine?
> If we do so, commands are not shown up on the target doesn't meet the requirements of commands.  After some thinking, I prefer registering mpx commands unconditionally even target doesn't support mpx.  The "show" command still can tell user that this command doesn't work on this target.  Otherwise, it should be confusing that some commands disappear silently
> --
> Yao (齐尧)

Hope I have answered your questions.

Thanks a lot and best regards,
-Fred
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

  parent reply	other threads:[~2015-07-01  9:30 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-23 18:31 Doug Evans
2015-06-23 18:55 ` Patrick Palka
2015-06-23 19:03   ` Doug Evans
2015-06-23 20:17     ` Keith Seitz
2015-06-23 20:53       ` Doug Evans
2015-06-23 21:45         ` Patrick Palka
2015-06-24 11:55           ` Yao Qi
2015-06-25 16:35             ` Tedeschi, Walfred
2015-07-01  8:49               ` Yao Qi
     [not found]                 ` <AC542571535E904D8E8ADAE745D60B1944445D44@IRSMSX104.ger.corp.intel.com>
2015-07-01  9:30                   ` Walfred Tedeschi [this message]
2015-07-02 10:09                     ` Yao Qi
2015-07-02 15:34           ` Yao Qi
2015-07-02 16:19             ` [PATCH] Don't throw an error in "show mpx bound" implementation Patrick Palka
2015-07-06  9:31               ` Yao Qi
2015-06-24 10:21 ` Several regressions and we branch soon Yao Qi
     [not found]   ` <87lhf8yz90.fsf@br87z6lw.de.ibm.com>
2015-06-25 13:34     ` Doug Evans
2015-06-25 18:00       ` Andreas Arnez
2015-06-30 15:21         ` Yao Qi
2015-06-30 18:09           ` Andreas Arnez
2015-07-01  8:01             ` Yao Qi
2015-07-10  9:33             ` Yao Qi
2015-07-10 16:12               ` Andreas Arnez
2015-07-10 16:23                 ` Ulrich Weigand
2015-07-20 15:08                   ` Andreas Arnez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5593B32F.6070503@intel.com \
    --to=walfred.tedeschi@intel.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox