This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Make 'symbol-file' not care about the position of command line arguments
On Wednesday, November 29 2017, Pedro Alves wrote:
> On 11/29/2017 10:42 PM, Sergio Durigan Junior wrote:
>> On Wednesday, November 29 2017, Pedro Alves wrote:
>>
>>> On 11/29/2017 09:44 PM, Sergio Durigan Junior wrote:
>>>> This is a bug that's been detected while doing the readnever work.
>>>> Currently if you use the 'symbol-file' command you have to be careful
>>>> about the position of each argument you pass on the command line.
>>>> This is because while parsing its arguments, if the command detects a
>>>> filename, it promptly calls 'symbol_file_add_main_1' without waiting
>>>> to see if there are other args on the line. This only affects the
>>>> '-readnow' argument so far, but while implementing the '-readnever'
>>>> command it also affected it.
>>>>
>>>
>>> Testcase or it didn't happen? :-)
>>
>> Can we negotiate this? :-)
>>
>> I absolutely agree (and should have written about it in the commit log),
>> but it's easier to write a testcase for the -readnever. Actually, I
>> have one already written. So I'd like to "postpone" the testcase until
>> the readnever feature is in. OK?
>
> Doesn't -readnow work for that just the same?
Well, yeah, I've just confirmed that it's possible to match
"...expanding to full symbols..." when -readnow is used, so it's
possible to provide a testcase even now, indeed.
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 hadn't really understood what this was about in the other thread.
>>> (Now I do.) I wonder whether it's really desirable to make this
>>> work. It seems to me that it's much more usual in GDB for option
>>> processing to stop at the first argument that doesn't start
>>> with '-'? I.e., like getopt on most platforms. (The related
>>> add-symbol-file command stands out as quite odd to me for
>>> explicitly wanting '-'-options after non-'-' options...)
>>
>> I didn't know getopt stopped processing after the first non-'-'
>> argument.
>
> Most implementations of getopt do. GNU getopt is known for
> reordering non-'-' arguments. You can override that by
> setting POSIXLY_CORRECT in the environment, for example.
>
>> 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.
>>
>> I find it very confusing to have positional arguments in a command line.
>> This is not intuitive, and there's usually no indication that the
>> command expects a fixed position for its arguments (as is the case with
>> 'symbol-file', for example). I consider this to be a bug, if you ask
>> me.
>
> In this case it's right there in the online help (since Tom's patch):
>
> (gdb) help symbol-file
> Load symbol table from executable file FILE.
> Usage: symbol-file [-readnow] FILE
Sorry, but to me this doesn't say much. I read this help and think "Oh,
-readnow can be passed as an option, OK." Maybe that's my fault, but if
I was writing a command like "symbol-file FILE" and just remembered that
I wanted -readnow, I would include it in the end of the line. In fact,
that's exactly what happened when I was testing -readnever. I saw that
the flag had no effect when the last parameter, which made me go after
the cause.
> 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? I mean, their only non-option argument is the
FILE, which won't have spaces (or will, but they'll be quoted like they
should).
Sorry for being so persistent, but I was bit by this bug and it wasn't
nice.
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/