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

["Tedeschi, Walfred" <walfred.tedeschi@intel.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4611 bytes --]

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
\x16º&Öéj×!zÊÞ¶êç×mµçÉb²Ö«r\x18\x1dn–­r\x17¬