From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by sourceware.org (Postfix) with ESMTPS id 207A8381DCF6 for ; Wed, 18 Mar 2020 20:43:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 207A8381DCF6 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=scottlinder.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=scott@scottlinder.com Received: from webmail.eu.com (webmail21.sd4.0x35.net [10.200.201.21]) (Authenticated sender: scott@scottlinder.com) by relay9-d.mail.gandi.net (Postfix) with ESMTPA id EE6AEFF808 for ; Wed, 18 Mar 2020 20:43:55 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 18 Mar 2020 16:43:55 -0400 From: scott@scottlinder.com To: Gdb Patches Subject: [RFC][PATCH] Support frames inlined into the outer frame Message-ID: <237802b049d5e89a6d556559815b6f20@scottlinder.com> X-Sender: scott@scottlinder.com User-Agent: Roundcube Webmail/1.3.8 X-Spam-Status: No, score=0.3 required=5.0 tests=KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Wed, 18 Mar 2020 20:43:58 -0000 AMD is working on a port of GDB for our GPUs based on the ROCm stack (https://rocm.github.io/). We recently open-sourced the fork at https://github.com/ROCm-Developer-Tools/ROCgdb. We hope to begin upstreaming patches where possible, and https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/767 is the first such patch. We frequently have functions inlined into the outermost frame. The current implementation which introduced `outer_frame_id` as a "valid" ID distinct from `null_frame_id` does not support this, asserting the need for both a valid and non-`outer_frame_id` ID to base the ID of the inlined frame on. This patch changes the definition of `outer_frame_id` slightly to effectively represent a class of IDs which identify a frame inlined into the outer frame. These differ in `artificial_depth`, but otherwise behave just as `outer_frame_id` in that they are `FID_STACK_INVALID`, yet `frame_id_p` returns `true` and they compare equal to each other. Running the testsuite both with and without the patch doesn't yield any obvious regressions, although I have not come up with a test case to prove this out on e.g. x86. Does this seem reasonable? It is a bit of a hack on a hack, considering the existing issues with `outer_frame_id` and the obvious desire to remove it completely. At the same time, there is a fair amount of thought and effort involved in making that change, and I think it can/should be done independently of fixing this bug. My feeling is this patch is a pretty non-invasive change that doesn't make the situation fundamentally worse, but any feedback is appreciated. Cheers, Scott