From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30631 invoked by alias); 6 Jan 2014 18:00:27 -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 30483 invoked by uid 89); 6 Jan 2014 18:00:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 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; Mon, 06 Jan 2014 18:00:25 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s06I0NTv013402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Jan 2014 13:00:23 -0500 Received: from barimba (ovpn-113-85.phx2.redhat.com [10.3.113.85]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s06I02WJ013329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 6 Jan 2014 13:00:09 -0500 From: Tom Tromey To: Doug Evans Cc: gdb-patches Subject: Re: [PATCH 3/3] move the "main" data into the per-BFD object References: <1389028297-16977-1-git-send-email-tromey@redhat.com> <1389028297-16977-4-git-send-email-tromey@redhat.com> Date: Mon, 06 Jan 2014 18:00:00 -0000 In-Reply-To: (Doug Evans's message of "Mon, 6 Jan 2014 09:39:19 -0800") Message-ID: <87vbxxm1nh.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-01/txt/msg00077.txt.bz2 >>>>> "Doug" == Doug Evans writes: Doug> Seems like there ought to be an invariant that there is only one Doug> main name. I ask because it's not clear this invariant is Doug> enforced (or if it is it's too subtle) and thus what if this loop Doug> finds the wrong one? I agree there's some room for improvement, but I don't think this series makes the code worse in any notable way. There is no such invariant today and I don't know how it would be enforced. I think the new code, if anything, is slightly more likely to get the correct answer, due to walking the objfiles in load order, rather than reverse order. For the DWARF reader at least this only even triggers for Fortran anyway (gdb doesn't handle DW_AT_main_subprogram yet), which I think implies a lower exposure to possible difficulties. Tom