From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79822 invoked by alias); 28 Dec 2019 10:02:47 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 79803 invoked by uid 89); 28 Dec 2019 10:02:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-21.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=improves, Temporary X-HELO: EUR05-AM6-obe.outbound.protection.outlook.com Received: from mail-am6eur05olkn2049.outbound.protection.outlook.com (HELO EUR05-AM6-obe.outbound.protection.outlook.com) (40.92.91.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 28 Dec 2019 10:02:43 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NWEumM8Mihs5C0QrUFlI3J5IDiNT1NNJoNKzz6HfKFkInR9v+/fsMkzMKdYB4V9qWbM/Gepd5+2ECn4Mxvi6MP/Me46ltY9mDwJzr3w90+oXvl7bl5r5doVIor29n3CGryJbNELiZdOdlt92MNdMfgHGT4lRhKygQVC+kd3nyFqkDFEwOGwq+UAdAW9k9HOLr9wZ5sByLsTbuj8W4wTQO5J5bVCFpQlJEN9Y3cWcAwo4JVnyEWdBY4Z2AHXJGz+iI69urz1Jqk83DR/JJlxIDQlio0bzaFDwxzDDFxICMCVpFBdoz33bSJK3DgMuMF4sM1Kk9IEe6BMnMVDRUoKgxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Aurl1Dz8L1GD/XfZRXq5rVdeHEaxw+iJejfWpG0uoXk=; b=kSKB47gyRYPnr1qAONmQ68Q9qnGIGp+saXJq9t9n0hLCtWdscHsK1MAbt4P+/Yl0jiG3VLeyzrSPMbND9LyPbq4HFB/yK7SljRlwL6BFmnJbL/GNKkIV84S+OS+QuqiE6hdS8Ml3mz2KcQ/SrY5zaG79j3NBndZBSqoNc0wfI7pZKgNqIHl4rjvUpqGddJ0WUgnPddzw4r0jSrglCWBmEqlaR1hpOXzY+fBPp3tWUjU/1f9JRv+8l0tR5yRoZXl3JYB6Ibdt9XkUrozTQv/6mTiKqhtxwXAvAL/GtQ6q4Z/eOgWTvYrleNObny4UxdkmQHkJGOTleQEfs5WTooqfvw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from VI1EUR05FT067.eop-eur05.prod.protection.outlook.com (10.233.242.57) by VI1EUR05HT049.eop-eur05.prod.protection.outlook.com (10.233.242.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11; Sat, 28 Dec 2019 10:02:40 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com (10.233.242.56) by VI1EUR05FT067.mail.protection.outlook.com (10.233.243.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11 via Frontend Transport; Sat, 28 Dec 2019 10:02:40 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com ([fe80::8dd1:fb18:6271:f769]) by AM0PR08MB3714.eurprd08.prod.outlook.com ([fe80::8dd1:fb18:6271:f769%7]) with mapi id 15.20.2581.007; Sat, 28 Dec 2019 10:02:40 +0000 Received: from [192.168.1.101] (146.60.252.106) by ZR0P278CA0027.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:1c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11 via Frontend Transport; Sat, 28 Dec 2019 10:02:40 +0000 From: Bernd Edlinger To: Andrew Burgess , Christian Biesinger CC: "gdb-patches@sourceware.org" Subject: Re: [PATCH 3/3] gdb: Better frame tracking for inline frames Date: Sat, 28 Dec 2019 10:02:00 -0000 Message-ID: x-microsoft-original-message-id: x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2019-12/txt/msg01054.txt.bz2 On 12/26/19 11:33 PM, Andrew Burgess wrote: > * Christian Biesinger [2019-12-26 07:24:39 +0100]: >=20 >> On Mon, Dec 23, 2019, 02:51 Andrew Burgess >> wrote: >>=20 >> > This commit improves GDB's handling of inline functions when there are >> > more than one inline function in a stack, so for example if we have a >> > stack like: >> > >> > main -> aaa -> bbb -> ccc -> ddd >> > >> > And aaa, bbb, and ccc are all inline within main GDB should (when >> > given sufficient debug information) be able to step from main through >> > aaa, bbb, and ccc. Unfortunately, this currently doesn't work, here's >> > an example session: >> > >> > (gdb) start >> > Temporary breakpoint 1 at 0x4003b0: file test.c, line 38. >> > Starting program: /project/gdb/tests/inline/test >> > >> > Temporary breakpoint 1, main () at test.c:38 >> > 38 global_var =3D 0; >> > (gdb) step >> > 39 return aaa () + 1; >> > (gdb) step >> > aaa () at test.c:39 >> > 39 return aaa () + 1; >> > (gdb) step >> > bbb () at test.c:39 >> > 39 return aaa () + 1; >> > (gdb) step >> > ccc () at test.c:39 >> > 39 return aaa () + 1; >> > (gdb) step >> > ddd () at test.c:32 >> > 32 return global_var; >> > (gdb) bt >> > #0 ddd () at test.c:32 >> > #1 0x00000000004003c1 in ccc () at test.c:39 >> > #2 bbb () at test.c:26 >> > #3 aaa () at test.c:14 >> > #4 main () at test.c:39 >> > >>=20 >> How come only #1 is printing the address? >=20 > Well..... >=20 > For inline frames the sal returned by find_frame_sal has a symtab and > line set, but doesn't have the pc or end fields set. >=20 > If we then look at frame_show_address it seems specifically designed > to return false for precisely the case we're discussing. >=20 > I agree with you that it seems odd that we only get the address for #1 > in this case. I considered this patch: >=20 > ## START ## >=20 > diff --git a/gdb/stack.c b/gdb/stack.c > index 22820524871..ce85a1183f0 100644 > --- a/gdb/stack.c > +++ b/gdb/stack.c > @@ -327,7 +327,7 @@ frame_show_address (struct frame_info *frame, > gdb_assert (inline_skipped_frames (inferior_thread ()) > 0); > else > gdb_assert (get_frame_type (get_next_frame (frame)) =3D=3D INLINE= _FRAME); > - return false; > + return frame_relative_level (frame) > 0; > } >=20=20 > return get_frame_pc (frame) !=3D sal.pc; >=20 > ## END ## >=20 > The addresses are printed more now, there's a few test failures that > would need to be checked first. >=20 Hmm.... In the case of inline functions the call stack would behave odd with this patch. Since the inline frames all share the same PC, the value is redundant, still different source line location is presented for each. Also when stepping in the inner frame, all inlined frames would also change the PC, so you get the impression that the inlined function is now called from a slightly different place. It might be more useful to add an info to the call stack, that a frame was inlined instead? #0 iii () at dw2-inline-many-frames.c:145 #1 inlined in hhh () at dw2-inline-many-frames.c:115 #2 inlined in ggg () at dw2-inline-many-frames.c:77 #3 inlined in fff () at dw2-inline-many-frames.c:92 #4 0x0000000000401226 in eee () at dw2-inline-many-frames.c:155 #5 0x0000000000401209 in ddd () at dw2-inline-many-frames.c:135 #6 inlined in ccc () at dw2-inline-many-frames.c:84 #7 inlined in bbb () at dw2-inline-many-frames.c:108 #8 inlined in aaa () at dw2-inline-many-frames.c:60 #9 inlined in main () at dw2-inline-many-frames.c:125 Bernd. > Ideally I would like to keep changing this behaviour separate from > this patch series, but I do think this might be something we should > consider changing. >=20 > Thanks, > Andrew >=20