From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10235 invoked by alias); 6 Jan 2014 18:23:04 -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 10187 invoked by uid 89); 6 Jan 2014 18:23:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vb0-f53.google.com Received: from mail-vb0-f53.google.com (HELO mail-vb0-f53.google.com) (209.85.212.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 06 Jan 2014 18:23:02 +0000 Received: by mail-vb0-f53.google.com with SMTP id o19so9347161vbm.12 for ; Mon, 06 Jan 2014 10:22:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5FdFAsxAXOGvo9FozPiQFdAAgkY1ZaPWB/6bR2N3Qt4=; b=S6qqPzDB3tpWqYC0rlvNLWX8zSUxXCsvCYpwMp1pzv5Tz15T714hDEVBPI9qvbI4Bz 6mWQiXx9hzXea1u5l5cGG/RL+VdLMYuTEM89hXbs6gIW77WCS/80THxDeuSeX658oufG KMA7Uw9JNjovvo6OBmaZJ2INNwa4iIduAAIeTG3odcn+tUoFJHa0PcpjO16DYQEctUi1 NJGvzW7cTUYPSJNWlCGQWuLvDXf0uTzolnROdPdzNXTinK+Fs+8EpoAwQ74eK35snMPj /in1PDFUXyjzKhldEeUcCcK4SUCaHUeqNaWyT+QF/6rAkOM91pLV+Bk1bwJ+YRu+29pk pZWw== X-Gm-Message-State: ALoCoQkazbl2jO2dNGpPANGJ/3i7LD3Jv+gykNaS/MAh2CmTGk99j0o/S11gLtNJflypXn3CmP2flL8r5D430oiu4actlYPyNZNax/3Z4pEJIKPT309gDbYY1viCxxl4pp1DWdti1qjPpBpFM2JowUcO2/YXU3rMk8zBz7gA+W2tM9e5RVDrcMmqfPYxgJXO4reQU4mjEr2DkKwBIArjY4OsNY/WLLDMsQ== MIME-Version: 1.0 X-Received: by 10.52.230.35 with SMTP id sv3mr4383766vdc.27.1389032579832; Mon, 06 Jan 2014 10:22:59 -0800 (PST) Received: by 10.52.248.65 with HTTP; Mon, 6 Jan 2014 10:22:59 -0800 (PST) In-Reply-To: <87vbxxm1nh.fsf@fleche.redhat.com> References: <1389028297-16977-1-git-send-email-tromey@redhat.com> <1389028297-16977-4-git-send-email-tromey@redhat.com> <87vbxxm1nh.fsf@fleche.redhat.com> Date: Mon, 06 Jan 2014 18:23:00 -0000 Message-ID: Subject: Re: [PATCH 3/3] move the "main" data into the per-BFD object From: Doug Evans To: Tom Tromey Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00079.txt.bz2 On Mon, Jan 6, 2014 at 10:00 AM, Tom Tromey wrote: >>>>>> "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. Sure. Can I ask for a comment in the code explaining why things are the way they are. E.g., the new code may be more correct, but relying on an implicit "walking the objfiles in load order, rather than reverse order" is a teensy bit on the subtle side. (btw, is it written down anywhere that ALL_OBJFILES traverses files in load order? If there is such an invariant, it would be good for future readers to know). I can't promise to remember this discussion when I'm in the code 6 months from now. :-)