From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) by sourceware.org (Postfix) with ESMTPS id 3E6213857807 for ; Mon, 10 May 2021 20:08:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3E6213857807 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 14AK40XY138799; Mon, 10 May 2021 20:07:58 GMT Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 38e285bt37-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 10 May 2021 20:07:58 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 14AK6hrF089937; Mon, 10 May 2021 20:07:57 GMT Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2168.outbound.protection.outlook.com [104.47.56.168]) by aserp3020.oracle.com with ESMTP id 38djf7g0rg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 10 May 2021 20:07:57 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aFM0IiC+kY0tBE/4MEfIOZIcRQx1nZtWyoYQgeFg5ZJJgH0bzfQqX682HpQE2aqdIAGHXkOOxzRvldLexZcjfpJq2YYiAchzPrjsN/GxquM6nrwgU21EalbnCPgsudEPqHZQDqL9wTUmY0OPYv329dsVT3pc60tK/Q77LpKWbJASoP7CoCJDd7ZyVYjulebIXMdpPhGxqfgB9nDA9kQBtK9F7VZE+yxc5xPp+uhfCbgBoi1VZDZfNKLFF6GZnjG5OfntljikrokCKq/REQQ0SkY+2Ly4rZqQrJwVuqPxbww+H/5JHMQyBVKM17V2lg01YA0dbP8s6xt3QUWUXs/ihA== 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=ZC7frUKPXrP/ibuGxfgJK8WbCTs/ayqm9HtvT3XtcJ0=; b=fG4wnlGjKQN4WXe8PxvoGrgUC5IFaRsovDsrbK37QkLeya7t8FN+OeF8eevxf5IXV6ZI5uWzuxZDeEHd5pXzheEQJzHKEsxRVQMPkdHdP07tSVpbC9GEhyTeWrQigKVHqsatZMtgwfniSFd1yqnCD5FP2bpIFkpNiQZ8D9LAiKwvx5+FYag535hmZcTqKE0QfEvn/taWCzSBjE7/3HtRgQJXXmQgOQXlu7DkfOuevzU0nRF0Z3AqPNv2yTCyXtBdko2Ip9BvR7rk+frRdNVr/R5RtVpeim9xmzKQwzsGqtpTW8DZe0SIyu/vA9QDxaNWCvawandNVEWpfe6dQMYIWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none Received: from DM5PR10MB2041.namprd10.prod.outlook.com (2603:10b6:3:111::16) by DM6PR10MB3978.namprd10.prod.outlook.com (2603:10b6:5:1fa::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.26; Mon, 10 May 2021 20:07:55 +0000 Received: from DM5PR10MB2041.namprd10.prod.outlook.com ([fe80::14a9:31e9:48af:5e4f]) by DM5PR10MB2041.namprd10.prod.outlook.com ([fe80::14a9:31e9:48af:5e4f%8]) with mapi id 15.20.4108.031; Mon, 10 May 2021 20:07:55 +0000 From: "Jose E. Marchesi" To: Simon Marchi Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 0/1] Integrate GNU poke in GDB References: <20210510151044.20829-1-jose.marchesi@oracle.com> <9f1f3ee3-f31e-2941-3f6b-f54552f5c16b@polymtl.ca> Date: Mon, 10 May 2021 22:07:44 +0200 In-Reply-To: <9f1f3ee3-f31e-2941-3f6b-f54552f5c16b@polymtl.ca> (Simon Marchi's message of "Mon, 10 May 2021 14:39:08 -0400") Message-ID: <87r1ieuzcf.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Content-Type: text/plain X-Originating-IP: [141.143.193.76] X-ClientProxiedBy: LO4P123CA0014.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:150::19) To DM5PR10MB2041.namprd10.prod.outlook.com (2603:10b6:3:111::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from termi.oracle.com (141.143.193.76) by LO4P123CA0014.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:150::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.24 via Frontend Transport; Mon, 10 May 2021 20:07:54 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c98d3c79-279e-4122-41a2-08d913ef4c9c X-MS-TrafficTypeDiagnostic: DM6PR10MB3978: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: p5eYPkz8X+G3lz4qag3emYNQ8NsPv0rhJjV/FvI5AZVu/XYle6IpPgS8iLHjAf7S6a02KJhYtTT9hvgdsfhUoShakAdBvjheoPWBIJYt0HSHNLXFETo6OTJ6jctUOY6NfL6OwUOCOa+GqQy1PITex0ZyYYsPLCCr5yQq1vt9cTPLz5oNTQcj+rc+Jqei7mRAITBZL/KCsWn3W26EAvxr5G0vBYUU7r1kOLKFJYUokbr4WF6fI/J9dGqFj9QurB8Um8lq3OJg8KtcrRbDoi+H6xogD6WCgpY5AEbFG/gIeNo0UyyZGh9p0MyfNplInRCbzVGAXzRwP7lwDIUo5Cn/uiDeWsf7QNMXsQxCnXJirrw4X34ddvr5QkOXXtTrnl6Px6V8LGyOw7+wToHlfVlRmrBaqucupayr8txfkYmySlLL120FhhUqLFWyQYIbpTCD8S8kRNrfnQjoXEPPg98TgHveZ8IK1orTq1i/dqTRjHWRiaa6RuI0lf6xlFzwNtelmjkoYw4VUlfyWphj3l1EgF+RRPFI7Ygl3FTpUFIFVb4akvZkewc24WZ5O/opYF0CJYI9nR/93OV72dypc4BkvhtR+eId9fynxLLs2OESaz650Y+PpEfRIkEHfwXThuB0YI1hqu8Qg40ei6B/QKIAbrYsmNm2saCWTC7bykFykV/yb1SE8wbmeF/25/aExpC34JCOoR8areo0Bmm5vAH6vq+iV/I9hBiwPXR+6kGtT6I= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR10MB2041.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(136003)(396003)(39860400002)(346002)(86362001)(6916009)(66556008)(66946007)(66476007)(38100700002)(83380400001)(6666004)(4326008)(5660300002)(6486002)(2906002)(38350700002)(956004)(2616005)(7696005)(966005)(478600001)(36756003)(186003)(16526019)(26005)(52116002)(316002)(8676002)(8936002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?mc/CxcUDRD/p2WvVgG2I2q59h2g4KPe92Ock+zFIMBCzLodL/uI3lsPhWgiG?= =?us-ascii?Q?/KT3aKDxZjQcGXWgOZAnisgHH36O+S2TJwV3BgI/VTr8EJf1oVgLbUYCxcxu?= =?us-ascii?Q?4pd27PwwNRelC0oDRz8Y+5QHwFn0+ibFseCNQDh72ZIyNgB8cyaLQWcBOI6F?= =?us-ascii?Q?qUbKVhTm+PdIdaOPDYLIVqyu6z7LaMNzPM+3gXAK+EHoB1NQIW/sB2UzwNyo?= =?us-ascii?Q?shO6pxGEZ0wvWbM9evA1y4ucdfO+Vf+xRgYRTTeALBPGTxK8LzEDE65Skgh4?= =?us-ascii?Q?N6uMXOX3rGo+NXhiyfNBNtIWUJcyo1dVYFLU2cA7/G8S5cDE4bJ7H8UK2E/p?= =?us-ascii?Q?H+p/el9sukQyMfxhs8g2SvqoozRGN7Y1aYv502LM+IkDz5SHB1gXsUHsvAbJ?= =?us-ascii?Q?gY4Y7LKUWFm8v5RbG6XbW4I+hFgmyepSVFfIuCqoVMm6Y18mIeCTuHSqTUZ6?= =?us-ascii?Q?k2MN5v2yFngRsjby1elXd0XTCw/CkGu0lLwekc89cw9pQlauf+QZJxNVOcyV?= =?us-ascii?Q?sEii1kh1J7/c/Vu6G6pCa/8bjGuD7iV/eov1DYtjKtidZERmCI2Gjf9bnOii?= =?us-ascii?Q?/wHzDwHV2EWmZclp6YlEjae7Pm5XJjxVbdJBnSS/0JXmTo10RiX/eiPKiNXz?= =?us-ascii?Q?blBVYCEm/+lZbfw/B+2OlqZy3Lpkn6LjkhrYqSEhyt9B8uuqTntEZAZYThCb?= =?us-ascii?Q?tMnNFYnlphVHeJBd+iXqoR6knTW4F9+TPl6iXvo9J/rrovTknIpuZoRXdDom?= =?us-ascii?Q?jg2H1TPk4kXWTw8S+TKf5FLfGZb3dnXvwjQvxNBG6xtRgSc6HXul2RYrBhGz?= =?us-ascii?Q?XwU56F9Bd7FVbt2ZHxeXUM5cgBan6+VqoGK6jVE4foJZUZYsLc7mggfdUsJm?= =?us-ascii?Q?1qtydq2mG2KGT5dGdJ9NF9MnnIvA/hLuj5/295uVozrOMmf49WzDWGmG1SsG?= =?us-ascii?Q?VA/8rOb4PD+ZgFdMe0fyODnuv34Ykw/7m0SKzLXqHRKLfx4vOG2UdvHOhfB5?= =?us-ascii?Q?sf8OHh7BAwQcqZvWcSK7Xk2dvmCEYoKDA9Elcyf1LbVhSjMkE4T55ppMjHfW?= =?us-ascii?Q?TQh0sJ6m09jjf8GcAHXweProkebaZk7pq6rKuyRnMT3e+KdGndGXb9EFh42O?= =?us-ascii?Q?PfjRTOizQRY8sDy0pycI1/EMi4CHw8FA3RH+h2fRQiURJzF9rPKGS1lCHH3y?= =?us-ascii?Q?xhvrnWoKhkQy1UvqO5lQEO8/7tTm2M1nIWHel1kTct3wqdAwh2IK1UHMI0UF?= =?us-ascii?Q?BHRW7001eUuVKZgsRuPGFNwuqSqPQycV3x7dkeJXMrELgrwO2AZUpAyC++rQ?= =?us-ascii?Q?DnqKIQtWkIuUTY3XlFHP7Hdf?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: c98d3c79-279e-4122-41a2-08d913ef4c9c X-MS-Exchange-CrossTenant-AuthSource: DM5PR10MB2041.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2021 20:07:55.5615 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: XDI71+VgH81uEaQ+35o+Tn3H21kyHPpBYDE92XSUMAp866KTykYfjg6UrKNb1oc8gG/yDyGciEkQg0yh+8b5kdeTsSvBh4VGLJzpaLIjTu0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB3978 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9980 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 mlxlogscore=999 adultscore=0 phishscore=0 mlxscore=0 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105100136 X-Proofpoint-GUID: paetUE_UQGq7UbusNDbZ1KMm7PFRXSaD X-Proofpoint-ORIG-GUID: paetUE_UQGq7UbusNDbZ1KMm7PFRXSaD X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9980 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=999 mlxscore=0 bulkscore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 clxscore=1011 impostorscore=0 phishscore=0 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105100136 X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham 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: Mon, 10 May 2021 20:08:11 -0000 Hi Simon. Thanks for the feedback. >> A few notes: >> >> - The poke support is optional, and built if specified with >> --enable-poke at configure time. > > If I look at this reference [1]: > > --enable-*/--disable-* arguments > > The arguments starting with --enable- prefix are usually used to > enable features of the program. They usually add or remove > dependencies only if they are needed for that particular feature > being enabled or disabled. > > --with-*/--without-* arguments > > The arguments starting with --with- prefix are usually used to > add or remove dependencies on external projects. These might add > or remove features from the project. > > I don't find this super clear, as we could always see it both ways. I > want to enable the support for running Python code, so I use > --enable-python, which has the side-effect of pulling libpython. Or I > want to make my project depend on libpython, so I use --with-python, > which has the side-effect of adding the "can run Python code feature" in > my project. > > But most of our dependencies on external libs are expressed with > "--with", so I'd go with "--with-poke". Ok, I will change it :) >> >> - Eventually we will probably want to ship some prewritten Poke >> code in a pickle gdb.pk. Would $pkddatadir/poke/ be a good >> location for Poke code distributed with GDB? > > So, /usr/share/poke? > > Would gdb.pk contain some poke code that gdb would use itself, or is the > goal to make that poke code available to other libpoke users (like the > poke cli)? > > If it's code that is only meant to be used by gdb, it would make sense > to have it in GDB's own data dir (/usr/share/gdb/poke). A bit like gdb > has some Python code it uses for itself, in /usr/share/gdb/python. Yeah that makes sense, /usr/share/poke for the first case, and /usr/share/gdb/poke in the second case. >> >> And a few questions: >> >> - Where am I supposed to cleanup and shut down the incremental >> compiler when GDB exits? I looked but I cannot find a >> counterpart to _initialize_FOO, like _finalize_FOO. > > See make_final_cleanup. Or, you can use an std::unique_ptr > specialization that calls your finalize function on destruction. If > that object is global (or static within a function), it will be > destructed when the program (GDB) exits. There was a discussion about > exactly this but for debuginfod recently: > > https://sourceware.org/pipermail/gdb-patches/2021-May/178578.html That unique_ptr approach should work. Will take a look to that discussion and DTRT. >> - There are many global parameters that can be configured in the >> poke incremental compiler: the numeration base used when >> printing values, the global endianness, a cut-off value for how >> many array elements are printed, and the like. Reasonable >> defaults for them are set in `start_poke', but I would like the >> GDB user to be able to change these settings. I could add a >> `poke-set SETTING [VALUE]' command, but I was wondering whether >> there is a better way, like a global register of settings >> already in GDB? > > Without more knowledge of how this all works, I'd say that > > set poke PARAM VALUE > show poke PARAM > > would be more GDB-ish. Yes that's what I had in mind :) > Is there a way for GDB to list all poke's parameters at startup, so it > could register them all as a "set/show" command in GDB? Yes, that is certainly possible. > As a result, the user could do "set poke " to see all > possible parameters, which I would find really nice. Definitely! > Although if you think we might ever need to add some GDB parameters that > are not poke parameters, but parameters about how GDB uses/integrates > poke, then there is a chance of clash in the "set poke" namespace. In > that case, we could put all poke's parameters under > > set poke parameter PARAM VALUE > show poke parameter PARAM > > This way, we could have distinct "set poke parameter foo ..." and "set > poke foo ...". Where is the interface to add the settings? >> - I am using target_{read,write}_raw_memory to access the >> target's memory. What is the difference between the raw and >> non-raw accessors? > > From target_read_raw_memory's doc: > > /* Like target_read_memory, but specify explicitly that this is a read > from the target's raw memory. That is, this read bypasses the > dcache, breakpoint shadowing, etc. */ > > > So, it bypasses a cache in GDB (not sure why that's important). But > most importantly, the non-raw version will hide the software breakpoint > instructions, it will replace them with the original memory contents, > whereas the raw version will not. > > Let's says that the user decodes some memory where a breakpoint is, using > target_read_raw_memory will return the memory contents with the > breakpoint instruction. I think that most of the time, the user will > actually want to decode the original contents, so using > target_read_memory would be better. > > And if you write memory with target_write_raw_memory, I guess you can > end up overwriting a breakpoint, so that's not good. So I'd probably > use target_write_memory. Ok, I will change to use the non-raw versions. >> - How can I demangle C++ identifiers? And how can I detect when >> a given type is a C++ one that needs demangling? > > I think that we usually rely on the language of the compilation unit, as > given by DWARF, to know that a symbol has a C++ mangled name and needs > demangling. > > But otherwise, see the gdb_demangle function. Will do. Thanks!