From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1276 invoked by alias); 7 Aug 2017 11:29:23 -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 1253 invoked by uid 89); 7 Aug 2017 11:29:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*r:sk:static. X-HELO: mail-io0-f182.google.com Received: from mail-io0-f182.google.com (HELO mail-io0-f182.google.com) (209.85.223.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 07 Aug 2017 11:29:17 +0000 Received: by mail-io0-f182.google.com with SMTP id c74so1526682iod.4 for ; Mon, 07 Aug 2017 04:29:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=WdY4G3qMJlid82uAIeP/K3wlyY8CASKiw7kZ99Yc0gU=; b=r5NQzkPRlo40FMJg6MyyeMzUKO/8F5Kh1iaqqC1dV9qNWKluy/iy7qzwZRwY1VF6GS AfYo1VOQODTjYxjFCUxw8gi94bosm3vwU0qV6eot3gVi192RfLNMZufoFgZcw98sH2ve iM0chqwTsVXu4ey0T+JPklad8qMzLJTmG8TpwvmHeodaPy9USMhoEmf6CGY6wQEde+bg ZEvYoXMLHkQJlDZgE4OEVtJsWQWrlwHxt40z/0yrB4I9QnPGLvOlIjM7oiHHsISECJp+ Tjdgsf39wWUhycxYF49GDoz/fFjc55l3wROEgGvKLGcL42v77DPPVnE6gX1UPObhyaIH NXjw== X-Gm-Message-State: AHYfb5jSH1Jl83j4pEOQ/AV1ViJEAejqN2LWEFMYvQrfPAW65VMLYMe3 dfwuC0Nvj3kWhfud X-Received: by 10.107.18.41 with SMTP id a41mr134537ioj.315.1502105355991; Mon, 07 Aug 2017 04:29:15 -0700 (PDT) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id u63sm1830884ioe.85.2017.08.07.04.29.14 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 07 Aug 2017 04:29:15 -0700 (PDT) From: Yao Qi To: "Wiederhake\, Tim" Cc: "gdb-patches\@sourceware.org" Subject: Re: [PATCH 4/6] Dwarf: Fortran, support DW_TAG_entry_point. References: <1500629040-12972-1-git-send-email-tim.wiederhake@intel.com> <1500629040-12972-5-git-send-email-tim.wiederhake@intel.com> <86tw1q2jt3.fsf@gmail.com> <9676A094AF46E14E8265E7A3F4CCE9AF5AC20F28@irsmsx105.ger.corp.intel.com> Date: Mon, 07 Aug 2017 11:29:00 -0000 In-Reply-To: <9676A094AF46E14E8265E7A3F4CCE9AF5AC20F28@irsmsx105.ger.corp.intel.com> (Tim Wiederhake's message of "Fri, 4 Aug 2017 11:03:32 +0000") Message-ID: <86a83b1urh.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00115.txt.bz2 "Wiederhake, Tim" writes: >> Why return PC_BOUNDS_HIGH_LOW, which means both DW_AT_low_pc and >> DW_AT_high_pc are found. However, DW_TAG_entry_point doesn't have >> DW_AT_high_pc. The question is why do we call dwarf2_get_pc_bounds for >> DW_TAG_entry_point. Is it because we call read_func_scope for >> DW_TAG_entry_point? > > I may be misunderstanding you here. Yes, DW_TAG_entry_point doesn't > have DW_AT_high_pc but we know that value implicitly from the surrounding > subprogram, as explained in the comment above. > Yes, the comments above are clear to me. My question is why do we need to know the bounds or scope for DW_TAG_entry_point? Is there anything wrong if we don't get bounds or scope for DW_TAG_entry_point? >> > + } >> > + >> > attr_high =3D dwarf2_attr (die, DW_AT_high_pc, cu); >> > if (attr_high) >> > { >> > @@ -16029,6 +16103,7 @@ load_partial_dies (const struct die_reader_spe= cs >> *reader, >> > && abbrev->tag !=3D DW_TAG_constant >> > && abbrev->tag !=3D DW_TAG_enumerator >> > && abbrev->tag !=3D DW_TAG_subprogram >> > + && abbrev->tag !=3D DW_TAG_entry_point >> > && abbrev->tag !=3D DW_TAG_lexical_block >> > && abbrev->tag !=3D DW_TAG_variable >> > && abbrev->tag !=3D DW_TAG_namespace >> > @@ -16155,6 +16230,7 @@ load_partial_dies (const struct die_reader_spe= cs >> *reader, >> > if (load_all >> > || abbrev->tag =3D=3D DW_TAG_constant >> > || abbrev->tag =3D=3D DW_TAG_subprogram >> > + || abbrev->tag =3D=3D DW_TAG_entry_point >>=20 >> Could you update the comments above this block? > > > Sorry, which comments specifically? > The comment directly above the last block states: > DW_AT_abstract_origin refers to functions (and many things under the > function DIE [...])" Ah, the comments I mentioned are, /* For some DIEs we want to follow their children (if any). For C we have no reason to follow the children of structures; for other languages we have to, so that we can get at method physnames to infer fully qualified class names, for DW_AT_specification, and for C++ template arguments. For C++, we also look one level inside functions to find template arguments (if the name of the function does not already contain the template arguments). For Ada, we need to scan the children of subprograms and lexical blocks as well because Ada allows the definition of nested entities that could be interesting for the debugger, such as nested subprograms for instance. */ we need add comments for Fortran and entry_point after them. --=20 Yao (=E9=BD=90=E5=B0=A7)