From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by sourceware.org (Postfix) with ESMTPS id 6D5003858C50 for ; Thu, 31 Mar 2022 10:17:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6D5003858C50 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f49.google.com with SMTP id r7so13938603wmq.2 for ; Thu, 31 Mar 2022 03:17:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=rUZ2A75PGNpGubgKPWceHG/jZI6LjXQ5P7lRKQsynOg=; b=o2PzzoSUyRJbzcaZXa9/2fE0nJlVzS/9WhXztvQ3abr8nSyzDpYBGLp/EwCW60X1IP G1NKKzRDkg09c0KFqgRcc6ohfL5YRyUZmsf57fZi4/KWtuJ8/9SWyJQW0DCd0lPxj83t Nb/2Do22hekdKE80hUWPLhzerxD3180L9L8FF8iaY2zivBwIOqGs8RTBN2/yQtzoQnQH hBkbVwk0XWV17bpIuxaAk9R7I0kO9koNCPPPcJ5C1azvoxtRdWe4DyxtrcSTiaqrLbez WOxYIf/kr/lx9TbFZytZkEgCtPXfEe/TRfF1HEsA/q7PVaWShcQxKJWjupUAQPV4qxJN Zg5Q== X-Gm-Message-State: AOAM53336eMh8Adl0WQ0sbtFdCfni7Hdx92Tb0X4IA7NwPJHsXQ+a4ta jthrEMEc6FlzYvOE3tTk32oUH9vPgK6mgg== X-Google-Smtp-Source: ABdhPJzWXO3Wq94g+/bg+dzZ1h+N1ZJ/67iXN1hjoK3YEN1e2Q9MPS5tACyPQIyYXQ6abVxZKGqhzA== X-Received: by 2002:a05:600c:19ce:b0:38c:dcc1:4cf3 with SMTP id u14-20020a05600c19ce00b0038cdcc14cf3mr4094537wmq.126.1648721831368; Thu, 31 Mar 2022 03:17:11 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id h3-20020adffd43000000b00205dc8459e5sm3530508wrs.7.2022.03.31.03.17.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Mar 2022 03:17:10 -0700 (PDT) Message-ID: Date: Thu, 31 Mar 2022 11:17:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH v2 2/2] gdb: Add support for DW_LNS_set_prologue_end in line-table Content-Language: en-US To: Lancelot SIX , gdb-patches@sourceware.org Cc: lsix@lancelotsix.com References: <20220330093458.148497-1-lancelot.six@amd.com> <20220330093458.148497-3-lancelot.six@amd.com> From: Pedro Alves In-Reply-To: <20220330093458.148497-3-lancelot.six@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.7 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2022 10:17:14 -0000 On 2022-03-30 10:34, Lancelot SIX via Gdb-patches wrote: > This commit proposes to add support for the prologue_end flag in the > line-program processing. > > The processing of this prologue_end flag is made in skip_prologue_sal, > before it calls gdbarch_skip_prologue_noexcept. The intent is that if > the compiler gave information on where the prologue ends, we should use > this information and not try to rely on architecture dependent logic to > guess it. There's risk that this runs into compiler bugs, making the experience worse than if we use the existing code path. I wonder whether we should have a "maint set foo" knob for this. It's still early in the release cycle, so I'm OK with waiting a bit to see if we really need it, though. OTOH, having such a switch regardless would be useful for force-testing the prologue scanners. Hmm. > > The testsuite have been executed using this patch on GNU/Linux x86_64. > Testcases have been combiled with both gcc/g++ and clang/clang++ since combiled -> compiled > GCC does not set the prologue_end marker. No regression have been > observed with GCC or Clang. Note that when using Clang, this patch > fixes a failure in gdb.opt/inline-small-func.exp. Please mention GCC and Clang versions, for the record. > > diff --git a/gdb/buildsym.h b/gdb/buildsym.h > index 09c2d563ec9..252bad187dc 100644 > --- a/gdb/buildsym.h > +++ b/gdb/buildsym.h > @@ -115,6 +115,7 @@ struct context_stack > enum linetable_entry_flag : unsigned > { > LEF_IS_STMT = 1 << 1, > + LEF_PROLOGUE_END = 1 << 2, Please document this enumerator too. > + > + const struct symtab_and_line prologue_sal = find_pc_line (start_pc, 0); > + if (prologue_sal.symtab != nullptr > + && prologue_sal.symtab->language () != language_asm) > + { > + struct linetable *linetable = prologue_sal.symtab->linetable (); > + > + auto it = std::lower_bound > + (linetable->item, linetable->item + linetable->nitems, start_pc, > + [] (const linetable_entry <e, CORE_ADDR pc) -> bool > + { return lte.pc < pc; }); > + > + for (; > + it < linetable->item + linetable->nitems && it->pc <= end_pc ; > + it++) > + if (it->prologue_end) > + return {it->pc}; > + } Space/tab mismatch, I guess, since { and } don't align here in the patch. > + > + return {}; > +} Otherwise LGTM.