RFC: "set" command with 2 arguments instead of one?

RFC: "set" command with 2 arguments instead of one?

[Joel Brobecker]

Hello everyone,

Please see the following patch submission:
https://www.sourceware.org/ml/gdb-patches/2014-09/msg00869.html

It proposes the introduction of a couple of commands, one to dump
the contents of the of the bounds table, and one to set the bounds
for any given address. Since those commands are MPX-specific,
I would like to have them prefixed somehow. But the beyond the
fact that I'd like to have them prefixed, I was wondering if
set/show commands could be used for that. Eg:

    show mpx bound ADDR
    set mpx bound ADDR LBOUND UBOUND

The reason why I am asking for comments is that the "set" command
above has a syntax which is slightly unusual for "set" commands
in the sense that "set" commands nearly always only have one argument,
whereas it has 3 in this case.

I don't think that's an actual issue, as I don't see why we would
not want that and I do feel that "set mpx bound" sounds pretty
natural.

Any thoughts on the above?

Thank you!
-- 
Joel

Re: RFC: "set" command with 2 arguments instead of one?

[Andreas Schwab]

Joel Brobecker <brobecker@adacore.com> writes:

> It proposes the introduction of a couple of commands, one to dump
> the contents of the of the bounds table, and one to set the bounds
> for any given address. Since those commands are MPX-specific,
> I would like to have them prefixed somehow. But the beyond the
> fact that I'd like to have them prefixed, I was wondering if
> set/show commands could be used for that. Eg:
>
>     show mpx bound ADDR
>     set mpx bound ADDR LBOUND UBOUND
>
> The reason why I am asking for comments is that the "set" command
> above has a syntax which is slightly unusual for "set" commands
> in the sense that "set" commands nearly always only have one argument,
> whereas it has 3 in this case.

How do you parse the arguments if they are arbitrary expressions?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: RFC: "set" command with 2 arguments instead of one?

[Joel Brobecker]

> > It proposes the introduction of a couple of commands, one to dump
> > the contents of the of the bounds table, and one to set the bounds
> > for any given address. Since those commands are MPX-specific,
> > I would like to have them prefixed somehow. But the beyond the
> > fact that I'd like to have them prefixed, I was wondering if
> > set/show commands could be used for that. Eg:
> >
> >     show mpx bound ADDR
> >     set mpx bound ADDR LBOUND UBOUND
> >
> > The reason why I am asking for comments is that the "set" command
> > above has a syntax which is slightly unusual for "set" commands
> > in the sense that "set" commands nearly always only have one argument,
> > whereas it has 3 in this case.
> 
> How do you parse the arguments if they are arbitrary expressions?

I think that this is a question which is othogonal to the question
I am asking. If you need a command that takes multiple arguments,
and some of these arguments are going to be arbitrary expressions,
you're going to have a parsing problem regardless of the name of
the command you're choosing. And each command, regardless of the
name of the command they decide on, can determine how they handle it.
For instance, they could use quoting, a la shell.

But in the particular case that interests us, there are no arbitrary
expressions as of yet.

-- 
Joel

Re: RFC: "set" command with 2 arguments instead of one?

[Doug Evans]

On Sun, Nov 23, 2014 at 1:53 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> > It proposes the introduction of a couple of commands, one to dump
>> > the contents of the of the bounds table, and one to set the bounds
>> > for any given address. Since those commands are MPX-specific,
>> > I would like to have them prefixed somehow. But the beyond the
>> > fact that I'd like to have them prefixed, I was wondering if
>> > set/show commands could be used for that. Eg:
>> >
>> >     show mpx bound ADDR
>> >     set mpx bound ADDR LBOUND UBOUND
>> >
>> > The reason why I am asking for comments is that the "set" command
>> > above has a syntax which is slightly unusual for "set" commands
>> > in the sense that "set" commands nearly always only have one argument,
>> > whereas it has 3 in this case.
>>
>> How do you parse the arguments if they are arbitrary expressions?
>
> I think that this is a question which is othogonal to the question
> I am asking. If you need a command that takes multiple arguments,
> and some of these arguments are going to be arbitrary expressions,
> you're going to have a parsing problem regardless of the name of
> the command you're choosing. And each command, regardless of the
> name of the command they decide on, can determine how they handle it.
> For instance, they could use quoting, a la shell.
>
> But in the particular case that interests us, there are no arbitrary
> expressions as of yet.

This feels like a case where we need to at least think about some
future-proofing.
One way some commands separate expressions is with commas.
I'm not fond of optional commas (setting aside the thread on
info macro -at LOCATION,).
IOW, if it turns out that we want to use commas down the road
to separate expressions here, then I'd prefer the commas
be required today.
E.g., set mpx bound ADDR, LBOUND, UBOUND

As for how to process multiple arguments to a "set" command,
one way would be to stage the value in a string parameter,
and then have a set handler post-process the result.

Re: RFC: "set" command with 2 arguments instead of one?

[Joel Brobecker]

> This feels like a case where we need to at least think about some
> future-proofing.
> One way some commands separate expressions is with commas.
> I'm not fond of optional commas (setting aside the thread on
> info macro -at LOCATION,).
> IOW, if it turns out that we want to use commas down the road
> to separate expressions here, then I'd prefer the commas
> be required today.
> E.g., set mpx bound ADDR, LBOUND, UBOUND

> As for how to process multiple arguments to a "set" command,
> one way would be to stage the value in a string parameter,
> and then have a set handler post-process the result.

I think using commas systematically is making it worse for ourselves,
since it prevents us from using gdb_buildargv to parse the command
arguments for us. Commas also have a meaning in C, so arguably
they could be used in expressions as well. But, if that's the way
people prefer, then having a standard gdb_buildargv-like API that
everyone consistently uses will make it easier for me to accept
that decision.

-- 
Joel

Re: RFC: "set" command with 2 arguments instead of one?

[Andreas Schwab]

Joel Brobecker <brobecker@adacore.com> writes:

> Commas also have a meaning in C, so arguably they could be used in
> expressions as well.

In C commas also have dual roles, so this shouldn't be a problem.  Comma
expressions are only useful for side effects anyway.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: RFC: "set" command with 2 arguments instead of one?

[Doug Evans]

On Sun, Nov 23, 2014 at 11:12 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> This feels like a case where we need to at least think about some
>> future-proofing.
>> One way some commands separate expressions is with commas.
>> I'm not fond of optional commas (setting aside the thread on
>> info macro -at LOCATION,).
>> IOW, if it turns out that we want to use commas down the road
>> to separate expressions here, then I'd prefer the commas
>> be required today.
>> E.g., set mpx bound ADDR, LBOUND, UBOUND
>
>> As for how to process multiple arguments to a "set" command,
>> one way would be to stage the value in a string parameter,
>> and then have a set handler post-process the result.
>
> I think using commas systematically is making it worse for ourselves,
> since it prevents us from using gdb_buildargv to parse the command
> arguments for us. Commas also have a meaning in C, so arguably
> they could be used in expressions as well. But, if that's the way
> people prefer, then having a standard gdb_buildargv-like API that
> everyone consistently uses will make it easier for me to accept
> that decision.

fwiw, I *like* buildargv.  But quoting expressions, not so much. :-)

In the end, for something like this I'm ok with either.

RE: RFC: "set" command with 2 arguments instead of one?

[Tedeschi, Walfred]

Joel, Andreas, Doug and all,


Sorry for the long delay here. Now I could come back to the patches again.

Was there any outcome on that discussion. How do you think I could use the multiple arguments?


Thanks a lot and regards,
-Fred

-----Original Message-----
From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Joel Brobecker
Sent: Monday, November 24, 2014 8:13 AM
To: Doug Evans
Cc: Andreas Schwab; gdb-patches@sourceware.org
Subject: Re: RFC: "set" command with 2 arguments instead of one?

> This feels like a case where we need to at least think about some 
> future-proofing.
> One way some commands separate expressions is with commas.
> I'm not fond of optional commas (setting aside the thread on info 
> macro -at LOCATION,).
> IOW, if it turns out that we want to use commas down the road to 
> separate expressions here, then I'd prefer the commas be required 
> today.
> E.g., set mpx bound ADDR, LBOUND, UBOUND

> As for how to process multiple arguments to a "set" command, one way 
> would be to stage the value in a string parameter, and then have a set 
> handler post-process the result.

I think using commas systematically is making it worse for ourselves, since it prevents us from using gdb_buildargv to parse the command arguments for us. Commas also have a meaning in C, so arguably they could be used in expressions as well. But, if that's the way people prefer, then having a standard gdb_buildargv-like API that everyone consistently uses will make it easier for me to accept that decision.

--
Joel
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

Re: RFC: "set" command with 2 arguments instead of one?

[Joel Brobecker]

> Sorry for the long delay here. Now I could come back to the patches again.
> 
> Was there any outcome on that discussion. How do you think I could use
> the multiple arguments?

I don't remember any reply to the message you quote above, which
summarizes my current thinking and position. As you indicate, it is
a question of making a decision.

Global Maintainers: What do you think? Let's make a decision so that
Walfred can resume his work on this.

Thanks!

> 
> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Joel Brobecker
> Sent: Monday, November 24, 2014 8:13 AM
> To: Doug Evans
> Cc: Andreas Schwab; gdb-patches@sourceware.org
> Subject: Re: RFC: "set" command with 2 arguments instead of one?
> 
> > This feels like a case where we need to at least think about some 
> > future-proofing.
> > One way some commands separate expressions is with commas.
> > I'm not fond of optional commas (setting aside the thread on info 
> > macro -at LOCATION,).
> > IOW, if it turns out that we want to use commas down the road to 
> > separate expressions here, then I'd prefer the commas be required 
> > today.
> > E.g., set mpx bound ADDR, LBOUND, UBOUND
> 
> > As for how to process multiple arguments to a "set" command, one way 
> > would be to stage the value in a string parameter, and then have a set 
> > handler post-process the result.
> 
> I think using commas systematically is making it worse for ourselves, since it prevents us from using gdb_buildargv to parse the command arguments for us. Commas also have a meaning in C, so arguably they could be used in expressions as well. But, if that's the way people prefer, then having a standard gdb_buildargv-like API that everyone consistently uses will make it easier for me to accept that decision.
> 
> --
> Joel
> 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

-- 
Joel

Re: RFC: "set" command with 2 arguments instead of one?

[Doug Evans]

On Tue, Apr 14, 2015 at 5:49 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Sorry for the long delay here. Now I could come back to the patches again.
>>
>> Was there any outcome on that discussion. How do you think I could use
>> the multiple arguments?
>
> I don't remember any reply to the message you quote above, which
> summarizes my current thinking and position. As you indicate, it is
> a question of making a decision.
>
> Global Maintainers: What do you think? Let's make a decision so that
> Walfred can resume his work on this.
>
> Thanks!

Hi.

As a data point, regarding this comment:

"Commas also have a meaning in C, so arguably they could be used in
expressions as well."

note that parse_to_comma_and_eval handles parenthesized expressions,
so one *can* use commas in expressions.  If they pose a problem to parsing
of the command then one can wrap that expression in parens.

E.g.,

(gdb) p $pc
$1 = (void (*)(void)) 0x400764 <main()+4>
(gdb) disas (($pc+42),($pc+0)),+16
Dump of assembler code from 0x400764 to 0x400774:
=> 0x0000000000400764 <main()+4>:       mov    $0x400860,%esi
   0x0000000000400769 <main()+9>:       mov    $0x401c80,%edi
   0x000000000040076e <main()+14>:      callq  0x400630
<_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
   0x0000000000400773 <main()+19>:      mov    $0x0,%eax

So I'm not worried about commas in expressions.

gdb is never going to be at a point where all commands can use buildargv.
I think choosing either buildargv or commas (using parse_to_comma_and_eval
or whatever) should consider what the arguments to the command are.
And since this command takes things that are more like expressions
than like strings, I'm leaning towards commas.


>> -----Original Message-----
>> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Joel Brobecker
>> Sent: Monday, November 24, 2014 8:13 AM
>> To: Doug Evans
>> Cc: Andreas Schwab; gdb-patches@sourceware.org
>> Subject: Re: RFC: "set" command with 2 arguments instead of one?
>>
>> > This feels like a case where we need to at least think about some
>> > future-proofing.
>> > One way some commands separate expressions is with commas.
>> > I'm not fond of optional commas (setting aside the thread on info
>> > macro -at LOCATION,).
>> > IOW, if it turns out that we want to use commas down the road to
>> > separate expressions here, then I'd prefer the commas be required
>> > today.
>> > E.g., set mpx bound ADDR, LBOUND, UBOUND
>>
>> > As for how to process multiple arguments to a "set" command, one way
>> > would be to stage the value in a string parameter, and then have a set
>> > handler post-process the result.
>>
>> I think using commas systematically is making it worse for ourselves, since it prevents us from using gdb_buildargv to parse the command arguments for us. Commas also have a meaning in C, so arguably they could be used in expressions as well. But, if that's the way people prefer, then having a standard gdb_buildargv-like API that everyone consistently uses will make it easier for me to accept that decision.
>>
>> --
>> Joel
>> 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
>
> --
> Joel

Re: RFC: "set" command with 2 arguments instead of one?

[Joel Brobecker]

> gdb is never going to be at a point where all commands can use buildargv.
> I think choosing either buildargv or commas (using parse_to_comma_and_eval
> or whatever) should consider what the arguments to the command are.
> And since this command takes things that are more like expressions
> than like strings, I'm leaning towards commas.

OK with me.

-- 
Joel

RE: RFC: "set" command with 2 arguments instead of one?

[Tedeschi, Walfred]

Doug and Joel,

I agree with the argument about the commas.
For instance parsing a more complex expression (an inferior call) will potentially have issues parsing to spaces. But will work using commas.

In this sense I am also for commas.

Joel, thanks a lot for raising this subject! 

I will send an reworked version using commas for review....

Thanks and regards,
-Fred 

-----Original Message-----
From: Doug Evans [mailto:xdje42@gmail.com] 
Sent: Monday, April 20, 2015 7:45 AM
To: Joel Brobecker
Cc: Tedeschi, Walfred; Andreas Schwab; gdb-patches@sourceware.org
Subject: Re: RFC: "set" command with 2 arguments instead of one?

On Tue, Apr 14, 2015 at 5:49 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Sorry for the long delay here. Now I could come back to the patches again.
>>
>> Was there any outcome on that discussion. How do you think I could 
>> use the multiple arguments?
>
> I don't remember any reply to the message you quote above, which 
> summarizes my current thinking and position. As you indicate, it is a 
> question of making a decision.
>
> Global Maintainers: What do you think? Let's make a decision so that 
> Walfred can resume his work on this.
>
> Thanks!

Hi.

As a data point, regarding this comment:

"Commas also have a meaning in C, so arguably they could be used in expressions as well."

note that parse_to_comma_and_eval handles parenthesized expressions, so one *can* use commas in expressions.  If they pose a problem to parsing of the command then one can wrap that expression in parens.

E.g.,

(gdb) p $pc
$1 = (void (*)(void)) 0x400764 <main()+4>
(gdb) disas (($pc+42),($pc+0)),+16
Dump of assembler code from 0x400764 to 0x400774:
=> 0x0000000000400764 <main()+4>:       mov    $0x400860,%esi
   0x0000000000400769 <main()+9>:       mov    $0x401c80,%edi
   0x000000000040076e <main()+14>:      callq  0x400630
<_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
   0x0000000000400773 <main()+19>:      mov    $0x0,%eax

So I'm not worried about commas in expressions.

gdb is never going to be at a point where all commands can use buildargv.
I think choosing either buildargv or commas (using parse_to_comma_and_eval or whatever) should consider what the arguments to the command are.
And since this command takes things that are more like expressions than like strings, I'm leaning towards commas.


>> -----Original Message-----
>> From: gdb-patches-owner@sourceware.org 
>> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Joel Brobecker
>> Sent: Monday, November 24, 2014 8:13 AM
>> To: Doug Evans
>> Cc: Andreas Schwab; gdb-patches@sourceware.org
>> Subject: Re: RFC: "set" command with 2 arguments instead of one?
>>
>> > This feels like a case where we need to at least think about some 
>> > future-proofing.
>> > One way some commands separate expressions is with commas.
>> > I'm not fond of optional commas (setting aside the thread on info 
>> > macro -at LOCATION,).
>> > IOW, if it turns out that we want to use commas down the road to 
>> > separate expressions here, then I'd prefer the commas be required 
>> > today.
>> > E.g., set mpx bound ADDR, LBOUND, UBOUND
>>
>> > As for how to process multiple arguments to a "set" command, one 
>> > way would be to stage the value in a string parameter, and then 
>> > have a set handler post-process the result.
>>
>> I think using commas systematically is making it worse for ourselves, since it prevents us from using gdb_buildargv to parse the command arguments for us. Commas also have a meaning in C, so arguably they could be used in expressions as well. But, if that's the way people prefer, then having a standard gdb_buildargv-like API that everyone consistently uses will make it easier for me to accept that decision.
>>
>> --
>> Joel
>> 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
>
> --
> Joel
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