From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id IGfhALOBmmCXPQAAWB0awg (envelope-from ) for ; Tue, 11 May 2021 09:08:03 -0400 Received: by simark.ca (Postfix, from userid 112) id F12581F11C; Tue, 11 May 2021 09:08:02 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,MSGID_FROM_MTA_HEADER,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 38D4C1E01F for ; Tue, 11 May 2021 09:08:00 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D604C388C021; Tue, 11 May 2021 13:07:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D604C388C021 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1620738479; bh=udcL+QhCjNPqw7ApW2B+8zoootDA6OOPymNOnubOVlo=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=jLYyqVhcVXruO5ewN0VKhfacLqAuy1P4pAslheu6wjUeOpgJFigtZMWnjXqKL5rlR LLDg7/dTd1iw0hMadD/8KR3bjcgbEFBB2z5UObl41de5ty/5Ifm2CTWOyGcif92nTv FmOSyGI8fMhs4kHnR7jRTSBp9mig6RKytGUmc1oM= Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) by sourceware.org (Postfix) with ESMTPS id E6DA9388A826 for ; Tue, 11 May 2021 13:07:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E6DA9388A826 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 14BD4J7P028024; Tue, 11 May 2021 13:07:53 GMT Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 38e285dvmy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 11 May 2021 13:07:53 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 14BD63FH169680; Tue, 11 May 2021 13:07:53 GMT Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2043.outbound.protection.outlook.com [104.47.66.43]) by userp3020.oracle.com with ESMTP id 38fh3wq840-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 11 May 2021 13:07:53 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TDKTOAkLb9L83udRsM09UHj2EcLdDdpGnPTR6Hq5PR8qmR+v1m5GFOwczaIpKGel0n0MoToqcNTKwLOlB+PYDt/jUSgAbvzJkEZCl6ZTGtrT0RYK7ziOTA7uafNryuLBbuXf6eq4F9oNOZHEXnSPDIO4miAV3Grh6lyK4OdKuQ89Lr7gImpOpK5txg4yl4GQZC+9pQ3HljU21U0pDTkjMglHoIovFzSU3fEwPLvrneTN+lN/NPqEDSJZhkNBBgCaoTj1bUKztlwgB4oh5LfMwVzp11nt01hjFjKcWTng0P7prhkHzkL1wYE1rXEPteaYJ/5SkWUTeLP7FoLKrlmyng== 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=udcL+QhCjNPqw7ApW2B+8zoootDA6OOPymNOnubOVlo=; b=Xsz16iFnON+SX5Rs9lhAL4F2hog1FszwTHkvarAoGIQad1U0aCCkka3wrmIDD0ozJx06AymWCSE5qANmCtX8awZoYT6gzXboSc/pt7sC/WNHyoDopPcmHH2b9Z1ALP94J+Wl/SuLBwWeAK6sSBs+lPtq4+7jybjWYvY8LeIpFXWVBu3luDUWK3aUP8GzYLe4gu4ZBT7K//BPBYrcVmRpj2jITiJV0e2K6rNHFe5DtYHfxJjgdbvRhCwlXfKti3JTI3JTpVWAiu9r7m16o898DZATvq3lSNEP/tawyMWvbTala7t+j+w7xzG85yjdn57ppyix6qWM6GzPqoljZXPHRw== 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 DM6PR10MB3900.namprd10.prod.outlook.com (2603:10b6:5:1fe::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.26; Tue, 11 May 2021 13:07:50 +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; Tue, 11 May 2021 13:07:50 +0000 To: Andrew Burgess Subject: Re: [PATCH 1/1] Integrate GNU poke in GDB References: <20210510151044.20829-1-jose.marchesi@oracle.com> <20210510151044.20829-2-jose.marchesi@oracle.com> <20210511073331.GU6612@embecosm.com> Date: Tue, 11 May 2021 15:07:42 +0200 In-Reply-To: <20210511073331.GU6612@embecosm.com> (Andrew Burgess's message of "Tue, 11 May 2021 08:33:31 +0100") Message-ID: <875yzps9k1.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.78] X-ClientProxiedBy: LO2P123CA0035.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600::23) 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.78) by LO2P123CA0035.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Tue, 11 May 2021 13:07:49 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e409aa92-a903-4aad-e69b-08d9147dc7a8 X-MS-TrafficTypeDiagnostic: DM6PR10MB3900: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6108; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 4CzTpnw97A/TjyynaFAtVpIwIFNqBIxJJiebv/K2PupNHweosjsJa1hernHkgC3zlHTVRdwTNsdV6lw3eGjsSGotaSYpBebBirpQj/Ep7ioymL+tfH6bsN8kZVLB6e6YfRedQE1etpiRxVwmKzOCJblaQOoqffZud+X3ApqKXik0QB5CKya0lI9CoYH5n9rBoxFNtO2TAm7oYQMLwuaGhLBYXirotFvluPBs3UVBkyFWjvn3brbanw1TPkX4mDUKUiHbugNBs2GQZmrpIYYQObDsxMxclKuFQ9RXZOJpUjAhqPI7Y4/vw+J+6bJvTtDGUelkfZzlD8f3WqslnGXmqXYAYzSXGRFgOrUkmd5adIGUzXMnW7Yx9i8M7FF0kqc2iGN1tqMHchpqGs0aK2LNShvkda9sR2UrK3OvT5mSpJqAz4l8psT7Xp4sm7oWptl0wDRVJTwGsbqPGdop39hG/OsKlDJBItmF/kIj7lUMvICoikm5h5x+DR8CwJT9j6tiVeda0FnG3aboES+gjYIToCWJXxC+GNi7oeMLTZ+ANoXNq0QSAuVJy5AhUQjKkXFPJJawR4ziWxlDwbWPwYBn3CSc0BVkQhvLrO7OQzBLhGgKvYX21G10reBVV1D+hSIDboJXpOcXZLfKoNoSnAP+W8JTMACm7dkTk0AwYPtc6ANJWazzUy0Y9Zl1DxX6ThtNfzzLwHiyOSUIM1aHGMqqn610zMdstnhAj2rcc1JWe8A= 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:(396003)(346002)(376002)(136003)(39860400002)(366004)(956004)(26005)(2616005)(6916009)(66946007)(66476007)(7696005)(38100700002)(186003)(2906002)(38350700002)(16526019)(52116002)(66556008)(36756003)(6486002)(4326008)(8676002)(8936002)(478600001)(316002)(86362001)(966005)(5660300002)(6666004)(83380400001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?auO4lRK2X46HNHPM95V9Ygl2Ft5jsmRYtlZ8iTuKOp211B/3VpaflALy9C88?= =?us-ascii?Q?FCxScDNB/shzhAXdZX+3VtNiEfzJl6hJQbukDrcR7GFRX/ieJvBJvbPuOfbk?= =?us-ascii?Q?kGJHUwINcIySr6xZjn20um3dGq43rf+PpQAZJAI/qVjLOGn3cdVPVz+k7VFC?= =?us-ascii?Q?wGWe7bGegleOF8R32DCLhButPl0sA0mVlNFQ2GV6fo4sP9QYAV7MuUQyhT0B?= =?us-ascii?Q?JVLHayXslDe+D7KbCTcbiH62bUDDwwWf4AGIYfl/P7nugy+gv8QY0ug8VfOg?= =?us-ascii?Q?3zYOkVtOsalEcJEVORkooqm0KNxyGmHywoxv4dtlVSJlKV9rnCBt7OVjjIjm?= =?us-ascii?Q?Yr8Nv+AQj9ibrDdfNuFFBDaHHNtyrU6pbDWYUNpD8O6odyk7qz2zlWojvdTU?= =?us-ascii?Q?2VfAfwAIEBoH5zo0ZCA1KBvQ6dI8+3v1P+7rHsOvZc8WldHgxLwvXlI2SQGm?= =?us-ascii?Q?K4yARE+moUU47Ruq1I3Osf0Kxg3WLGBZlWhn05Tpw0RViBwrq7M6oNB6cRj2?= =?us-ascii?Q?0MNxG+ZidGawxQe7FgDaeThQKunpt+xTu0K4oVi58LlLspiyy1WDk2usKHjx?= =?us-ascii?Q?UJUtb5+hL/wNufFBsEkvOYWHUXDEMZ6euojivyKociNRvvW421dAvKtW4oHJ?= =?us-ascii?Q?z+4R99668mSUArScBag3KmZtkjRcaRDlYYr5oxN9FZPbcqkWGsURRVJUeCuT?= =?us-ascii?Q?a1lLDMvdJCxFpV3ijRtu1nk9VUrnJsjprHxZr0pF3v+uGG/he65ttgc3B/Cg?= =?us-ascii?Q?eM4jTeZz9vVVO99QOsxLNjXMoCvIch1bY7oAFEiV6L2mXP4QQa7EcpwQeVNM?= =?us-ascii?Q?jI64jDZhhI4xDG1EdUiGTkMkg+LB0HdKTh3C+IicwGWq3LOa+0cYcEDZQ4fF?= =?us-ascii?Q?8FMLipMoNRMOXwfI9FxC162fzvJ0ypN3NwvvhbZ/ufbmTLQi0vkvPNsk1Fzl?= =?us-ascii?Q?AKTndRHIYoFJqxlO+g53qoFNWn+w94aw0axBvJQViIeUySx8hnx+8KuTbWhU?= =?us-ascii?Q?y6O2yUhR9XNQK6O42E/lcs26E+On7L5ABL9YLVRy9sG9VBlPzKPum49jsNDO?= =?us-ascii?Q?ASJOHxeLhOLaDH09t60Bl0C0A9c4qvvPSUXYFeMz4Y65xKfbcZ93sGziZeRc?= =?us-ascii?Q?ZyOFcE+lGzFBGchP3ee8cvZ8X2FAgaDS9ziiQAkIGoxlhpGFMqAsZeE8NY8x?= =?us-ascii?Q?UeFP0bWwk3klTTcYdFbO45L4uqKBDCZOasAg/tDJ5szn+QK41RjGU8xLS8os?= =?us-ascii?Q?0HeYwuXVeXahacv4ChJvqtpZRZl68K0hPB0e7shH0fcDVrseKZkFmhjVR0OK?= =?us-ascii?Q?qLqXzKKFARhs1V1zOUmLgVhq?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: e409aa92-a903-4aad-e69b-08d9147dc7a8 X-MS-Exchange-CrossTenant-AuthSource: DM5PR10MB2041.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2021 13:07:50.5107 (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: HACL+LerCi/FQqe8W1UWEpHhzNCWlGLOZCyV4KoxRlMKmnlHCZRop40y69p7CHjozozhUswOpjh1AApuFUyEzl/f3kzq4xa0NHPzBZOnMhY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB3900 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9980 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 suspectscore=0 malwarescore=0 adultscore=0 bulkscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105110100 X-Proofpoint-GUID: J7oxEIXEcL6xZzM5E3HhT1eQrwrNZpII X-Proofpoint-ORIG-GUID: J7oxEIXEcL6xZzM5E3HhT1eQrwrNZpII 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=1015 impostorscore=0 phishscore=0 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105110100 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: , From: "Jose E. Marchesi via Gdb-patches" Reply-To: "Jose E. Marchesi" Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Hi Andrew. Thanks for the feedback. > I have no objections to merging this functionality, especially as it > is so self-contained, however, I do have a question, or feedback. > > As someone who doesn't know poke, after reading the manual, it's still > not clear to me what significant value poke adds to GDB. A lot of the > examples seem to cover things that GDB already does, mostly examining > data and variables in target memory (though there were a couple of > neat features which aren't so easy to achieve in GDB). > > I guess my question, or feedback, would be, what's the killer feature > that adding poke brings to GDB? The most obvious example that quickly comes to mind is to check/debug the integrity of data in an application's memory. Suppose you have a program or driver that processes USB packets, and buffers them in some memory buffer. The program is malfunctioning and you suspect (but you don't know for sure) the culprit is some corrupted USB packet. So you want to examine the integrity of the USB packets that the program has buffered at certain point in the program execution. This is where poke gets handy: a pickle for USB packets (let's say usb.pk) will provide types/methods/functions describing the format of USB packets, including integrity. It will also likely provide utility functions for diagnostics, and even fixing invalid packets. GDB gives you access to the C/whatever-language types, and that is very good, but: - C/whatever language types do not include integrity checks. Poke types almost always do. - Poke types are designed to be used/interpreted/read by persons, whereas C/whatever types are designed to be interpreted by programs. As such, Poke types tend to "adapt" their form to their contents in order to be intelligible and to increase the odds of detecting integrity problems. - If the protocol/format/structure of the data being examined is bit-oriented (consider for example data compressed with deflate) the C/whatever types usually provide a byte-sized view of the structure instead of a meaningful structure that the person using GDB can easily understand/manipulate. Instead, poke can _really_ operate at the bit level. See the following section in the poke manual: http://www.jemarch.net/poke-1.2-manual/html_node/Weird-Integers.html#Weird-Integers For example, consider the following Poke type describing a type in BTF (the debugging format for BTF types): type BTF_Type = struct { offset,B> name; struct uint<32> { uint<1> kind_flag; uint<3>; uint<4> kind; uint<8>; uint<16> vlen; method _print = void: { printf ("#<%s,kind_flag:%u32d,vlen:%v>", btf_kind_names[kind], kind_flag, vlen); } } info; union { offset,B> size : (info.kind in [BTF_KIND_INT, BTF_KIND_ENUM, BTF_KIND_STRUCT, BTF_KIND_UNION]); BTF_Type_Id type_id; } attrs; type BTF_Member = struct { offset,B> name; BTF_Type_Id type_id; union { offset,b> member_offset : !info.kind_flag; struct uint<32> { offset,b> bitfield_size; offset,b> bit_offset; } bitfield; } offset; }; type BTF_Func_Proto = struct { BTF_Param[info.vlen] params; }; union { BTF_Int integer : info.kind == BTF_KIND_INT; BTF_Array array : info.kind == BTF_KIND_ARRAY; BTF_Enum[info.vlen] enum : info.kind == BTF_KIND_ENUM; BTF_Func_Proto func_proto : info.kind == BTF_KIND_FUNC_PROTO; BTF_Variable variable : info.kind == BTF_KIND_VAR; BTF_Member[info.vlen] members : (info.kind == BTF_KIND_UNION || info.kind == BTF_KIND_STRUCT); BTF_Var_SecInfo[info.vlen] datasec : info.kind == BTF_KIND_DATASEC; struct {} nothing; } data; method vararg_p = int: { var last_param = data.func_proto.params[info.vlen - 1]; return (last_param.name == 0#B && last_param.param_type == 0); } method get_kind_name = string: { return btf_kind_names[info.kind]; } }; If you map a BTF_Type from GDB, it will check the integrity (poke also support mapping in non-strict mode) and also will build the structure based on the very contents. GDB simply can't do the same thing based on the "equivalent" collection of decoupled C types, which are really not equivalent at all. So, back to the debugging of the USB processing program, sure, you could dump the buffer to some file using GDB commands and then use poke on the side to poke on it. But having poke in GDB allows you to inspect the buffer directly and the integrity of its contents, and also provides access to the rest of the program memory, which could be also handy to diagnose the problem. Now suppose you find something fishy in a USB packet, and what you want to do is to _fix_ it (or modify it somehow) and then continue the program to see if that fixes the crash. Again sure, you could use GDB commands to load the modified dump. But having poke in GDB allows you to just continue. This as for "what can poke do for GDB". But there is another aspect to consider as well: "what can GDB do for poke". You see, mainly for the sake of completion, we _do_ support a "proc" IO device in GNU poke (the command-line editor) that provides access to the memory of a running process. However, this support is intended only for the very basics, and: - It is not portable (only works on GNU/Linux). - It doesn't know how to recognize stack frames. - It doesn't know how to unwind. - It doesn't have a disassembler. - etc When people ask me to add features like that to poke (and they do ask) I always think: why bothering implementing them? GDB does all these things very well, and more, and it is portable, and it knows about a shitload of architectures, and... . So, in my mind, the right platform to use for poking at the memory of live (or even dead) processes is GDB. That's why we took pains to make it very easy to integrate poke (libpoke) in other applications, and therefore this proposed patch :) Another example of integration (which is work in progress) is with the assembler (GAS). Instead of writing this: .section .text .set softfloat .ascii "PS-X EXE" .byte 0, 0, 0, 0, 0, 0, 0, 0 .word main .word 0 .word 0x80010000 .word image_size .word 0,0,0,0 .word 0x8001FFF0 .word 0,0,0,0,0,0 .ascii "Sony Computer Entertainment Inc. for zid" You will be able to write something like: .poke load psxexe .poke var s = "Sony Computer" .poke PS_X_EXE { start = $main, size = $image_size, vendor = s } (A nice side effect will be that .poke will be a _really portable_ data directive, unlike the regular ones, and therefore we will be able to write, say, the GDB and linker tests for CTF the right way, i.e. without relying on a compiler or copy-pased inintelligible .word/.byte blocks.) I could go on and on but I don't want to pester you people so I better stop :)