From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 1BD8E3858D37 for ; Tue, 21 Mar 2023 14:44:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1BD8E3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1679409847; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GKqr8RCr/AMoqkiQSl3todZL0chz3bMhI2F4/6mvlMU=; b=hCg56wi0VkfX+S3R9baXso3LvFH6eqxgmFnUskJoB7f0gPU9v1K4+9npxfsVG8fLIClu11 uofahuncFbiycg6/AE8dX53qHnJz33ACtZ46BtXCxzL9vjvAuGNHspPeVioS5ydRjSS/8S y6kKvx2zMtm0bQzhRt5pGNr2qG2CVDk= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-184-YvjPBCQEPxGOPnjx0rQHJw-1; Tue, 21 Mar 2023 10:44:05 -0400 X-MC-Unique: YvjPBCQEPxGOPnjx0rQHJw-1 Received: by mail-ed1-f71.google.com with SMTP id es16-20020a056402381000b004fa3e04c882so22198232edb.10 for ; Tue, 21 Mar 2023 07:44:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679409844; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GKqr8RCr/AMoqkiQSl3todZL0chz3bMhI2F4/6mvlMU=; b=5yMRkd3H726k5h9J7akGYdBdgWB+OQwBLfsV0sqPeKEFkwS8A8n0Geiry969PXDm6S bJX7CRBf+5H1ZZYNYRa5bykx+LSxE2//w5xbOFUHnoS/2gCGWo0XgICom19yoiwdkw0o 7O5ubiptsCvacrVWERD0+lmfP0MvnUtsyaSju3sR0WPFztMol2vfvcDcsm4C+QL+jZ0w 7ePdWDVhuw6TPOgLdXcLkcfiruehEKAE4Um7XPnrifKHBYbiwwnRlgSwQ4HPcRZ+yPox 8hBRCg2Y71/XCqLBMiuau2ICq0i8fHTjSZa6qZYGxSQjV5/Im7WaIKOpCf+xgQyxe/Uu j7iA== X-Gm-Message-State: AO0yUKUblJzcHPLY2LeY4J2Tfp2a/tMDtRnaPVpktBz3/UJcndnh0CpO ptBTPCymFW18lWAE8yZBS8hmVNLV7qDokxNIB5+TXktEmcXRq0lBSsQjMNN4EYNjc0anS+iXXLA 23RpKvE9IKq9judDa3cq+utjT3ii7kQ== X-Received: by 2002:a17:906:2802:b0:878:7a0e:5730 with SMTP id r2-20020a170906280200b008787a0e5730mr2774680ejc.56.1679409843879; Tue, 21 Mar 2023 07:44:03 -0700 (PDT) X-Google-Smtp-Source: AK7set8OBd5m8iD8CR/j6FVjvHVK8sDIM2dujWputiMWmvUwve2FR6x5Jy4dGX9OxX7wEda+sBWRkg== X-Received: by 2002:a17:906:2802:b0:878:7a0e:5730 with SMTP id r2-20020a170906280200b008787a0e5730mr2774659ejc.56.1679409843565; Tue, 21 Mar 2023 07:44:03 -0700 (PDT) Received: from [10.43.2.105] (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id hf8-20020a1709072c4800b0092b65c54379sm5904606ejc.104.2023.03.21.07.44.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Mar 2023 07:44:03 -0700 (PDT) Message-ID: <69e067fd-5e8d-0629-89f2-082df4c87254@redhat.com> Date: Tue, 21 Mar 2023 15:44:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH 1/1] gdb: Avoid warning for the jump command inside an inline function. To: "Willgerodt, Felix" , "gdb-patches@sourceware.org" Cc: Pedro Alves References: <20230124151932.2471769-1-felix.willgerodt@intel.com> <103d7434-d7ad-b03b-5724-d6f9d6846749@redhat.com> <3619ffc8-1050-c586-3da4-e98dc0649754@redhat.com> From: Bruno Larsen In-Reply-To: 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: 8bit X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 21/03/2023 15:05, Willgerodt, Felix wrote: >> -----Original Message----- >> From: Bruno Larsen >> Sent: Freitag, 17. März 2023 14:34 >> To: Willgerodt, Felix ; gdb- >> patches@sourceware.org >> Subject: Re: [PATCH 1/1] gdb: Avoid warning for the jump command inside >> an inline function. >> >> On 17/03/2023 13:56, Willgerodt, Felix wrote: >>>> -----Original Message----- >>>> From: Bruno Larsen >>>> Sent: Freitag, 17. März 2023 11:14 >>>> To: Willgerodt, Felix ; gdb- >>>> patches@sourceware.org >>>> Cc: Cristian Sandu >>>> Subject: Re: [PATCH 1/1] gdb: Avoid warning for the jump command >> inside >>>> an inline function. >>>> >>>> On 24/01/2023 16:19, Felix Willgerodt via Gdb-patches wrote: >>>>> When stopped inside an inline function, trying to jump to a different line >>>>> of the same function currently results in a warning about jumping to >>>> another >>>>> function. Fix this by taking inline functions into account. >>>>> >>>>> Before: >>>>> Breakpoint 1, function_inline (x=510) at jump-inline.cpp:22 >>>>> 22 a = a + x; /* inline-funct */ >>>>> (gdb) j 21 >>>>> Line 21 is not in `function_inline(int)'. Jump anyway? (y or n) >>>>> >>>>> After: >>>>> Breakpoint 2, function_inline (x=510) at jump-inline.cpp:22 >>>>> 22 a = a + x; /* inline-funct */ >>>>> (gdb) j 21 >>>>> Continuing at 0x400679. >>>>> >>>>> Breakpoint 1, function_inline (x=510) at jump-inline.cpp:21 >>>>> 21 a += 1020 + a; /* increment-funct */ >>>>> >>>>> This was regression-tested on X86-64 Linux. >>>>> >>>>> Co-Authored-by: Cristian Sandu >>>>> --- >>>>> gdb/infcmd.c | 3 +- >>>>> gdb/testsuite/gdb.base/jump-inline.c | 30 +++++++++++++++++ >>>>> gdb/testsuite/gdb.base/jump-inline.exp | 45 >>>> ++++++++++++++++++++++++++ >>>>> 3 files changed, 77 insertions(+), 1 deletion(-) >>>>> create mode 100644 gdb/testsuite/gdb.base/jump-inline.c >>>>> create mode 100644 gdb/testsuite/gdb.base/jump-inline.exp >>>>> >>>>> diff --git a/gdb/infcmd.c b/gdb/infcmd.c >>>>> index fd88b8ca328..40414bc9260 100644 >>>>> --- a/gdb/infcmd.c >>>>> +++ b/gdb/infcmd.c >>>>> @@ -1091,7 +1091,8 @@ jump_command (const char *arg, int from_tty) >>>>> >>>>> /* See if we are trying to jump to another function. */ >>>>> fn = get_frame_function (get_current_frame ()); >>>>> - sfn = find_pc_function (sal.pc); >>>>> + sfn = find_pc_sect_containing_function (sal.pc, >>>>> + find_pc_mapped_section (sal.pc)); >>>> Hi Felix, >>>> >>>> Thanks for doing this, it is a good improvement, but I don't know if >>>> this is the best way to go about it. Is there a reason why >>>> find_pc_function should not return inlined functions? >>>> >>>> I feel like most of the time we want to know the function, knowing if >>>> we're in an inlined one would be desirable, but I might be wrong. Does >>>> anyone know? >>>> >>> Hi Bruno, >>> >>> I don't know the details, but the comments in symtab.h are rather explicit >>> about it, so I assume there is a reason: >>> >>> >>> /* lookup the function symbol corresponding to the address. The >>> return value will not be an inlined function; the containing >>> function will be returned instead. */ >>> >>> extern struct symbol *find_pc_function (CORE_ADDR); >>> >>> /* lookup the function symbol corresponding to the address and >>> section. The return value will be the closest enclosing function, >>> which might be an inline function. */ >>> >>> extern struct symbol *find_pc_sect_containing_function >>> (CORE_ADDR pc, struct obj_section *section); >> Hi Felix, >> >> I thought it was mostly a descriptive comment, rather than prescriptive. >> I tested changing find_pc_function locally and there were only 2 >> regressions, which might just be broken assumptions, but our testsuite >> is probably not very comprehensive on inlined functions, so I don't know >> how representative this test actually is. >> > Hi Bruno, > > Could you share what changes you have done locally? > Did you basically just change find_pc_function to call > find_pc_sec_containing_function? Hi Felix Yeah, this is exactly what I did. > > I saw that there is another comment in blockframe.c about > "backwards compatibility", but that has been in the code for ages and > I couldn't find anything interesting related to it. Backwards compatibility is part of the reason I'm hesitant to trust my results. Fedora has very new everything, so I don't get to trigger bugs in old compilers or setups if we dont have a test manually recreating that. The other part is some other compiler/language/combination of things that could go wrong. I hope Pedro can remember the original reasoning! > > When git blaming the comments in symtab.h, I saw they were added > by Pedro a couple years ago: > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;f=gdb/symtab.h;h=cd2bb709940d33668fe6dbe8d4ffee0ed44c25e6 > Maybe he can help shed some light on this? > > Thanks, > Felix > Intel Deutschland GmbH > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 -- Cheers, Bruno