From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16847 invoked by alias); 9 Aug 2010 21:16:20 -0000 Received: (qmail 16838 invoked by uid 22791); 9 Aug 2010 21:16:19 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,TW_BJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.35) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Aug 2010 21:16:13 +0000 Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o79LG9gY020784 for ; Mon, 9 Aug 2010 14:16:10 -0700 Received: from vws13 (vws13.prod.google.com [10.241.21.141]) by wpaz17.hot.corp.google.com with ESMTP id o79LFgnK008381 for ; Mon, 9 Aug 2010 14:16:08 -0700 Received: by vws13 with SMTP id 13so9145019vws.34 for ; Mon, 09 Aug 2010 14:16:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.90.212 with SMTP id j20mr9860304vcm.207.1281388568093; Mon, 09 Aug 2010 14:16:08 -0700 (PDT) Received: by 10.220.201.197 with HTTP; Mon, 9 Aug 2010 14:16:07 -0700 (PDT) In-Reply-To: References: Date: Mon, 09 Aug 2010 21:16:00 -0000 Message-ID: Subject: Re: [0/4] RFC: add DWARF index support From: Doug Evans To: Tom Tromey Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes 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 X-SW-Source: 2010-08/txt/msg00116.txt.bz2 On Mon, Aug 9, 2010 at 1:36 PM, Tom Tromey wrote: >>>>>> "Doug" =3D=3D Doug Evans writes: > > Doug> I don't want to unnecessarily delay the patch (given, for example, = its > Doug> size), but not generating an index file when asked to and not flagg= ing > Doug> an error feels wrong at a gut level. > > For our particular use (RPM builds), we'll just ignore errors anyhow, > because (IMO) it is more important for the build to succeed than for > this optimization to be applied. Are you sure you'll just ignore *all* such errors? I suspect you'd want to at least catch, for example, spelling errors in file names passed to the script. Otherwise you'll trip over problems downstream when simple things such as this could be caught up front. > There are a few problems here if you want it to work the other way. Yep. > First, main.c doesn't play well with errors. =A0When processing -ex > arguments we just ignore error returns, and then later call quit_force, > which exits with status 0. =A0I think this makes sense to change, but I > have not thought through all the ramifications, or tried to research the > history. > > Second, save_gdb_index_command prints the error but doesn't propagate > it. =A0Since it loops over all objfiles this seemed nicest. =A0But, we do= n't > use it that way from this script; maybe we could add a "-fail" option to > the command or something like that. Well, -fail should be the default, and if one wants gdb to be usable in these kinds of scripting situations, error catching should be a general facility rather than adhoc additions to particular commands. For reference sake, some alternatives: - don't loop, specify the objfile instead? - don't exit half-completed - e.g. if one fails they all fail > I think I will just revert the gdb-add-index.sh addition, since it has > too many problems. =A0I'll revisit it when I can spend some time fixing up > -batch. =A0I'll send a reversion patch tomorrow. > > Doug> E.g., I wonder what should happen if there isn't enough (or any) in= fo > Doug> to generate .gdb-index. > Doug> Is that an error? > > I guess it could be. =A0I don't really care much about the various > pathological cases. Well, there are various kinds of pathological cases. I think we should at least invest time thinking about things the user is likely to trip over. [I'd also want to make sure we're on the same page as to what is pathological, I suspect we are not.] > Doug> I hate to add another wrinkle, and thanks for bearing with me. > Doug> I just tried passing a file that doesn't exist. =A0gdb writes somet= hing > Doug> to stderr and then exits with a zero exit code. > Doug> That needs to be flagged as an error (presumably with test -r or so= me > Doug> such before invoking gdb) , but it could be deferred to another pat= ch. > > This is the main.c problem. =A0The "file" command fails, but that doesn't > affect operation. Right, but this is a common thing that can be tripped over, and trivially dealt with in the script (e.g. with test -r), at least until gdb supports being scripted better. [For pedantic completeness sake, there would a window between doing the test -r and the file command, but *I'm* not suggesting handling that *pathological* case! :-)]