This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Make 'symbol-file' not care about the position of command line arguments


On Wednesday, November 29 2017, Pedro Alves wrote:

> On 11/30/2017 12:08 AM, Sergio Durigan Junior wrote:
>> On Wednesday, November 29 2017, Pedro Alves wrote:
>> 
>> I'll wait until we reach a conclusion on whether this patch is useful or
>> not, and then submit the testcase along with v2.
>
> I don't mind this going in, provided it comes with a testcase.

I'm working on it right now.

>>>> I've always considered that passing '--' is the de facto way
>>>> of telling getopt (or argp) to stop processing.
>>>
>>> "--" is used to stop processing options when you want to pass
>>> a non-option argument that starts with "-", like imagine if you
>>> wanted to pass a filename that starts with "-" to symbol-file
>>> (the filename is not an option.)
>>
>> Ah, true, that makes sense.
>>
>
> ... which points out that we should really handle "--", for
> the possibility of such filenames.
>
> (At some point we should really come up with some getopt-like
> API that can be used by all the commands that also use gdb_argv,
> to help with normalizing the interface, and also to make it
> easier to add new options to commands.)

That'd be super.  It's been on my mind for quite some time, too.  I'm
impressed such interface doesn't exist yet.

>>> Note that supporting non-option arguments before options
>>> is impossible for commands that need to handle raw arguments.
>>> I.e., commands that want to supporting passing arguments
>>> arguments with spaces, without forcing the user to wrap it
>>> all in quotes.  Like "break -q function (int)", or
>>> "print /x EXPRESSION_WITH_SPACES", etc.  (I have a WIP series
>>> that adds '-'-options to "print", btw.)
>>> It's good to keep the possibility of the command being extended
>>> in that direction in mind.  It doesn't seem to be the case
>>> here, but that's the angle I was coming from.
>> 
>> I agree, but that's not the case with 'symbol-file' or
>> 'add-symbol-file', right?  
>
> Yes, that's what I said - "it doesn't seem to be the case here".
>
> Are we still negotiating?  Can I get you to make
> "add-symbol-file" process options in any position too?  :-)

Sure thing!  I'll give it a try.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]