From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id OavcL6qttWnhbykAWB0awg (envelope-from ) for ; Sat, 14 Mar 2026 14:49:14 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=oiUp6Da4; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id ABF401E0DD; Sat, 14 Mar 2026 14:49:14 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 15C441E089 for ; Sat, 14 Mar 2026 14:49:14 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id BBBCA4C31894 for ; Sat, 14 Mar 2026 18:49:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BBBCA4C31894 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=oiUp6Da4 Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 389FD4B1A2E8 for ; Sat, 14 Mar 2026 18:48:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 389FD4B1A2E8 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 389FD4B1A2E8 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=132.207.4.11 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773514127; cv=none; b=BIv3ZNA+jgYTqHkcQqmC7DCDyOQam16nAeVMKFX1DaEV2Kyh9Y7aajTTGX/oCOozTmC2NY1XIUPWAfho6cgC1/Qf+8zPGaw1jpuVHvxLHhzWbSXKH2/Przud2Z4fdiyJvJZNAt5lW1uPTrmbBsYOh762WOfS9sKKvtzymGcS6SI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773514127; c=relaxed/simple; bh=lNpcmIQYm5l25XMbQUxqelRYgzhbxq+XDdbgADwbf3E=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=fjz+Lj8Wzi2nX0YnGt4Zv/MsP4blxDqaGnw8X2LeIeHIZ4wus8qUyr750e1swysSbXiaSZtOe9jN4UFU/58IWf0kLn4yF6NjkxCtng4gZSjUFGmgKHZBxzPBRAqVJIYdlI5ls1ySPm3ixlwQVALLiRH5TKw/rc/8TzFdQjolz38= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 389FD4B1A2E8 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 62EImflI138874 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Mar 2026 14:48:46 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 62EImflI138874 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=oct2025; t=1773514126; bh=oyVgwmkXmMnWjxW758JwRAPrAau0paH4JOGHxy2iSUs=; h=Date:Subject:To:Cc:From:In-Reply-To:From; b=oiUp6Da4Bgu2dGr8g45Tqk2ZWfYhY9U/1EVDXYShRx1QNK33dGLR+TDF1QlLp0DzK 7+R6WFQsIkhP3LH5dsow520H4ELBJXK1Zdppy1sh+KggCa9+fxcQKbiEAxtYaAHLlk yv1Xd40ak9f60GUwqlD16zgRb9q118Uk9yp2HmW97Dzo8h4wFMdpel/+Xk9rfH5flb wMdcJ/IXA1LQtQ0OJ1TtuBrk8HjUU2jc5hxSKYaJsvdtfhdABt7DBNGcQY+6aWT0fN reKa/ZgMfnERPriKu+wIONyC3QstyjSLBzBoB4GeoOnTx4JObp4kRddpFEH8vnd1zQ qyBrq3LoYYBug== Received: by simark.ca (Postfix) id 3227D1E089; Sat, 14 Mar 2026 14:48:41 -0400 (EDT) Message-ID: <986c042d-86b5-4e9e-a7b2-b95ee9745743@polymtl.ca> Date: Sat, 14 Mar 2026 14:48:40 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 5/5] gdb: make find_memory_region_ftype a function_view To: Tom Tromey Cc: gdb-patches@sourceware.org References: <20260310173104.676640-1-simon.marchi@polymtl.ca> <20260310173104.676640-5-simon.marchi@polymtl.ca> <87a4wbr2hx.fsf@tromey.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <87a4wbr2hx.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Sat, 14 Mar 2026 18:48:41 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 2026-03-13 14:46, Tom Tromey wrote: >>>>>> "Simon" == simon marchi writes: > > Simon> From: Simon Marchi > Simon> Make it a function_view and remove the `void *` parameter. Convert the > Simon> callers (in gcore.c) to use lambda functions that capture `obfd`. > > Simon> One thing is that I am not sure how to implement > Simon> target_debug_print_find_memory_region_ftype now... right now I made it > Simon> return a constant "" string. > > I think this is fine. Some of these debug printers are already not > really that useful. > > Simon> To make target.h see find_memory_region_ftype, I added an include of > Simon> gdbarch.h in target.h, I'm not sure if this is undesirable, possibly > Simon> causing some circular include problem in the future. > Simon> find_memory_region_ftype was previously in defs.h. Leaving it there > Simon> would require including gdbsupport/function-view.h inside defs.h, which > Simon> I would prefer not to do. An alternative would be to place > Simon> find_memory_region_ftype in a smaller (perhaps a new) header file, but I > Simon> don't really know which one. > > It's tempting to try to fix it now before it is a problem. > > Though I somewhat suspect that what you have already is fine. > > I do think having a new small header just for this type would be > completely fine and I think it's a reasonable long-term strategy for > handling this kind of "pro forma" typedef. As in, I'd encourage this in > other cases where breaking circular dependencies is needed. > > Anyway I also think this is ok. > Approved-By: Tom Tromey Well, it does feel wrong to have the typedef in gdbarch.h, because it is not more a "gdbarch.h" thing than it is a "target.h" thing. Both headers are equal users of the typedef. So I think it makes sense for it to be in a third header that they both include. I will send a new patch where the typedef is in a new file called `find-memory-region.h`. Simon