From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0EmtC4kWXWT0IAcAWB0awg (envelope-from ) for ; Thu, 11 May 2023 12:23:37 -0400 Received: by simark.ca (Postfix, from userid 112) id 2CB401E11E; Thu, 11 May 2023 12:23:37 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=LDx3o3qG; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C5F111E114 for ; Thu, 11 May 2023 12:23:36 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2F8BD3857006 for ; Thu, 11 May 2023 16:23:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2F8BD3857006 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1683822216; bh=N+KTqlVv8EpVWmHRByTYclEwYAZCfE/dtgPYPCy8FlM=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=LDx3o3qGhGf/6omp9Ak6JwGBvvsStkDVqvhoaz5rWYn3uxsBErrPH+oBXSJzddQ2/ GUZww416utZInb7yGpNM0YzhGTYHNNLYPu6GKQcxpDRHwqaCvvWwCBaJ7Vdonfwth1 mzrQ4qUNzSnXmgC3X4kok84RybtOSl9vqb+GJDdw= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 9E9A33858C5F for ; Thu, 11 May 2023 16:23:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9E9A33858C5F Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-19-8EkKjeS6NWWAnedyjCtfnQ-1; Thu, 11 May 2023 12:23:12 -0400 X-MC-Unique: 8EkKjeS6NWWAnedyjCtfnQ-1 Received: by mail-qv1-f70.google.com with SMTP id 6a1803df08f44-61b78e49e99so45507536d6.1 for ; Thu, 11 May 2023 09:23:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683822192; x=1686414192; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=N+KTqlVv8EpVWmHRByTYclEwYAZCfE/dtgPYPCy8FlM=; b=dHktPOIjhOeZtYP1bnz4bt/dC2Lv+yE6cCQc94zkVM76Fi1SR1BR+YjfRRoJWnhLEc a7Q7VHEXmoOzM30Ee8sX31KQGVSPeVM7u6snVnLRcE0Tp2bZoVeVkUeTM5lbWaKkcluy ZhfHCxTJ58eZloSrMLSicjArwd+TAUxfKV966aA0uO1IIwR/Rlmp1jEsjRFCFhQLW71+ /rovoa2ahUtYztmFsNJRhYZlYbUrVj9U4wMFPiBJte9KbqrulkJMYwDzMlQDGRKxxORE VQIRyCBvgTd9tLM6w//+YIpkDJ0Xg4o5gMSygRiJhxzpUHwg3yAabB/HW0AnVwFSDAFK +5KQ== X-Gm-Message-State: AC+VfDzvEHzZYHCme5Twe/tqGXWtpR4ZaySogotqE0xMBxsb8gd8MPB8 4qIHQq4npZrm8Vb7OAyAYNGSfgMrNzdWerwwLgh6L6BvpEohhRb1U8IOcjFhaDgvo0Y5dxXSEc4 QXn9nTCeo2QppUHtz5ROxNA== X-Received: by 2002:a05:6214:29ca:b0:621:2b0f:9f17 with SMTP id gh10-20020a05621429ca00b006212b0f9f17mr18818434qvb.6.1683822192464; Thu, 11 May 2023 09:23:12 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6ax4SwnpySpmcNpWPB+eIR3xUD8TLJcg2u0xbRsBNjOIreDvenPYayfMBmsgk7bBtAhEKpGQ== X-Received: by 2002:a05:6214:29ca:b0:621:2b0f:9f17 with SMTP id gh10-20020a05621429ca00b006212b0f9f17mr18818406qvb.6.1683822192197; Thu, 11 May 2023 09:23:12 -0700 (PDT) Received: from [192.168.0.45] (ip-94-112-225-44.bb.vodafone.cz. [94.112.225.44]) by smtp.gmail.com with ESMTPSA id c16-20020a0cca10000000b0061b721f27b3sm2362619qvk.123.2023.05.11.09.23.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 May 2023 09:23:11 -0700 (PDT) Message-ID: Date: Thu, 11 May 2023 18:23:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v4] Fix reverse stepping multiple contiguous PC ranges over the line table. To: Simon Marchi , Carl Love , gdb-patches@sourceware.org, UlrichWeigand , pedro@palves.net Cc: luis.machado@arm.com References: <74630f1ccb6e9258ae60682105ee5490726fb255.camel@us.ibm.com> <46d73c69-9168-44c6-b515-23dd893fc0eb@redhat.com> <86c65f2ad74caffc162f100e4e9c5be9062a7f59.camel@us.ibm.com> <0a2c4ebd-f01d-4b96-1b13-25d7276056a5@redhat.com> <956b8c3c9a7bdc3aa6f9a040619ec4778edc9c94.camel@us.ibm.com> <89b2fb027024f7e97de7196ee091a0ca11c0c2b3.camel@us.ibm.com> <0943e12c-049d-f8b0-c4c5-8816b1be1e45@simark.ca> In-Reply-To: <0943e12c-049d-f8b0-c4c5-8816b1be1e45@simark.ca> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: , From: Bruno Larsen via Gdb-patches Reply-To: Bruno Larsen Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 11/05/2023 18:01, Simon Marchi wrote: >> +with_test_prefix "with-column-info" { >> + run_tests >> +} > So, the above assumes that the compiler generates column-info by > default, which has not historically been the case for GCC (it started to > emit columns by default with version 8, according to my tests). Other > compilers may choose to not emit them by default. Yes, column info started being generated in gcc7 and was made default in gcc 8 > > I think it would make sense to make gdb_compile recognize the new > "column-info" and "no-column-info" options, which would translate to the > right flags for the given compiler. gdb_compile already handles the > nitty gritty details of choosing compiler flags for specific compiler > versions. This way, individual tests don't contain compiler flags that > are possibly compiler-specific. > I was going to suggest something similar in an earlier revision, but when I tried to look for how to control it in clang, I couldn't see it at all, that's why I thought it was OK to restrict it to gcc only. Can clang (or other compilers for that matter) emit this information? Also, how would gdb_compile handle if the current compiler doesn't support a given option, but the others do? Should it loudly fail, or silently ignore the "broken" option? If the second, I guess there is no harm in allowing clang to run these tests and testing the same scenario twice -- Cheers, Bruno