From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10071 invoked by alias); 29 Nov 2017 23:15:51 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 10056 invoked by uid 89); 29 Nov 2017 23:15:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=negotiate, online X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Nov 2017 23:15:49 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 781AA77356 for ; Wed, 29 Nov 2017 23:15:48 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2A6305C888; Wed, 29 Nov 2017 23:15:44 +0000 (UTC) Subject: Re: [PATCH] Make 'symbol-file' not care about the position of command line arguments To: Sergio Durigan Junior References: <779a2d21-badf-b54c-e1c9-2f869716fd71@redhat.com> <20171129214451.14257-1-sergiodj@redhat.com> <196b7212-6a93-8c39-a86e-c5782f470d1e@redhat.com> <87d140emfr.fsf@redhat.com> Cc: GDB Patches From: Pedro Alves Message-ID: Date: Wed, 29 Nov 2017 23:15:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <87d140emfr.fsf@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-11/txt/msg00806.txt.bz2 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? >> 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.) > > 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 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. Thanks, Pedro Alves