From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39639 invoked by alias); 1 Jun 2018 15:17:05 -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 39328 invoked by uid 89); 1 Jun 2018 15:17:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.2 spammy=ptrace, UD:aarch64-sve-linux-ptrace.h, gradually, Ptrace X-HELO: sesbmg22.ericsson.net Received: from sesbmg22.ericsson.net (HELO sesbmg22.ericsson.net) (193.180.251.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 Jun 2018 15:17:00 +0000 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 96.6A.00712.563611B5; Fri, 1 Jun 2018 17:16:53 +0200 (CEST) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSHC008.ericsson.se (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 1 Jun 2018 17:16:53 +0200 Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Jun 2018 17:16:53 +0200 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 1 Jun 2018 17:16:52 +0200 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; Received: from [142.133.49.220] (192.75.88.130) by DM6PR15MB2394.namprd15.prod.outlook.com (2603:10b6:5:8d::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.797.11; Fri, 1 Jun 2018 15:16:50 +0000 Subject: Re: [PATCH 8/8] Ptrace support for Aarch64 SVE To: Alan Hayward CC: "gdb-patches@sourceware.org" , nd References: <20180511105256.27388-1-alan.hayward@arm.com> <20180511105256.27388-9-alan.hayward@arm.com> <752617dd-3221-7aa7-d626-b841fe13761c@ericsson.com> <22AC70D2-D24D-4DE9-939F-067BE65F02F3@arm.com> From: Simon Marchi Message-ID: <0ff06fe2-396d-a9da-d95b-130f6bef2d2c@ericsson.com> Date: Fri, 01 Jun 2018 15:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <22AC70D2-D24D-4DE9-939F-067BE65F02F3@arm.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SN4PR0501CA0136.namprd05.prod.outlook.com (2603:10b6:803:2c::14) To DM6PR15MB2394.namprd15.prod.outlook.com (2603:10b6:5:8d::28) X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020);SRVR:DM6PR15MB2394; X-Microsoft-Exchange-Diagnostics: 1;DM6PR15MB2394;3:xxaufmMsno6N/l3Js778sS/0MO0kULvu4CYEzpOXHzIlGqvMQ+8ORFcLJNz8VYTJl8vpzt6jbR2iyLuZnx5noSJRJK58VGNdNn+aZFcVkZPsY/oINZfCqiZX0GE6cqHzal+DINwSDsezCBD9BLa5uePh+50uSYluYv1On/IGQjYtm84mu70+w0e7fJN4Ws25aP+FLdaKLkETCFC+oL9Q28zSHzraJMKmfbleywjHe7pd8I6oDoZtCELPSyp+tX1K;25:GNN3+0A3Coghx9ycpKNql366ke9IbRLOb6vGHFgaw7TBZVVK4aMMZmXHdLk24dQFufROPdaplra5N0tsE31V7lRzymOylu11M9/PJryRwdNaERPmh4+R56QK4PjTJL7iM6IliyCr5YHMuUb192Gz+KHxbRJn1PJyc52qr8Mo5buD3PTvX+4zzqZQ4VrJyg9MTP+oy+5FnXSRCkzZhI8dzTJ48TGzxoDOA3VNoYy1WG1AtZrNw9P2rA4Mo1xR8SpfTBzoR6Y0i2yqT58iqrgXmwt4+W6uUvoTCpcfdhe4S0N4WoULuc3WERNmPB08IouQkhsGJHMo6eWVAIQz44nfqg==;31:YzijMlk0PhOHR+6M1Rc1LxygHL+ohTzxT6hV98cgd+1mOheP8OjW2tbf0J+22sae35hAG7BphGWlBM+wOJMayqM1S2bvY+qCom18wShliwfW7+TGcDfAyQTbTYdEr3ZBtFzvrwFGv6aLND7MNwfJm7TkZgvfg9YrcAosGBY79ATG2Gz3Zr/LftTcD0RNBWhjyw2Lv90nkSDnx8xyZbAfPKyWykSnj57N6fxi/QVX0RM= X-MS-TrafficTypeDiagnostic: DM6PR15MB2394: X-Microsoft-Exchange-Diagnostics: 1;DM6PR15MB2394;20:HUFIxa769RxKh6IXGOQZZnsbxG4mWDIaSPG30sE2np/PsyUP2qvoBRt74jeiZl1NrXb8I/aClsTapi1N8hTh/dxk13cTjna3eWPevw46sS5FjHSZ1Dm4ZLc3Ol68Q+T2sXSTG/bGvzhgCYlOX7YLs2/X5xx153FW/Wez5FlYhLwi0cKh00MBAYqqnuQxFWP11ntu3YP//oPhUPXYMtxyF64tPRLTP+KJd2QUBL8Eg8ZjRgtSIBlu6JjvRNmWCymXvXpDIKvGmMztMRblkWJoDla3A/VC92L1scREVR+9xBhsgkiR+Jr0TgKHLWUUGypTS/X180iWxALIRsZ+/fkctjB3dfXlXwdOlXvgHOFdhfjyUGjE5NPsVSYOWFLwW6XETBPq2xzfqcKH8x+wWfrGjNCEO1liPfqoLhXa87o4VQAzKT5+3tfg/2sBX+ts8kpMveEwHmuxqZ+ByXwX5+bogq2kd3mcz9Ct8Jx2eommfDhWxlsbk6Ab8U30aBKUfWeZ;4:kMvwB9NJ6W0UEeuHfQFmzTFIPxKcGNnbJaUTJSuUKf4Vh9MLf5uT+N3cYoLLIz+7qgvZDA3ehMVPBURzDpyudeeAJV/I5ITp1Bs5SgcPK9csXRs3MTts9CRk0vImZ61eTU5r7WRibzNQio/11oc72eypws6mnNrOuDETXlcymwuxT3pFbCggXmQxZQiwizwG8pFF1ht+tr8xcLGQIRhhSRv23mvZINoFRNdoGLlouFVF4yEtHoDi76Q1/hdEwZROsP+bIpSQ3AedarniOIYJiT+Otw9bs8j/2XGyzHqzeRxnoIHoe8+C6LJzYKUja/bI X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016);SRVR:DM6PR15MB2394;BCL:0;PCL:0;RULEID:;SRVR:DM6PR15MB2394; X-Forefront-PRVS: 0690E5FF22 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6049001)(376002)(346002)(39860400002)(39380400002)(366004)(396003)(189003)(199004)(6306002)(59450400001)(53936002)(52146003)(316002)(2906002)(93886005)(52116002)(53546011)(4326008)(386003)(68736007)(26005)(6246003)(31686004)(2486003)(6916009)(65826007)(966005)(36756003)(54906003)(25786009)(16576012)(6666003)(58126008)(478600001)(5660300001)(76176011)(229853002)(86362001)(31696002)(305945005)(64126003)(16526019)(7736002)(186003)(23676004)(8676002)(50466002)(81166006)(81156014)(6486002)(2616005)(11346002)(486006)(476003)(65806001)(47776003)(44832011)(956004)(65956001)(66066001)(8936002)(446003)(6116002)(106356001)(49976009)(97736004)(105586002)(3846002)(2870700001)(78286006);DIR:OUT;SFP:1101;SCL:1;SRVR:DM6PR15MB2394;H:[142.133.49.220];FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTZQUjE1TUIyMzk0OzIzOm93dkhVMlk5VUpFMlFZL1IvTGNWWFpIZTAz?= =?utf-8?B?blVjZFZnYzg0MDJaN0hsMUVCNjhmdGRLTitCRUJMNFlUUEJZbnQ4eWw3UVdD?= =?utf-8?B?UWJSQkVYQkJxOU1WQkZRd2N3WXMzbjdSN2hHY2RPdDh4cUdDQ0IwTXQ3Y0pC?= =?utf-8?B?MGZsd1FFQXNwU3kxNUdWaVR6SnNoRjhveUpXTGhGanNCb0E4MlJZbHNpOVFh?= =?utf-8?B?bFNNdjgwL1kwQ00wazlqRldrdm0wck0xVE9ESmt2OXdJVDhjNFVRMDdTT1lB?= =?utf-8?B?NEdGU0VMMHJnTVlFb0w4dTViTzErVWRRMEJKYUdzRm95dzVncnFZaTg0alJ4?= =?utf-8?B?aTA2bkkzNlFmNzhicVU3b0RDMjJORVB2YXRBMHpkTUNLVXhBYVJzSis4YXM1?= =?utf-8?B?SURIZ1M4UkRyNVBVVmU0S3lUTktxUjBkMEF4ZmdnUUFpbFhleVJvK2d2bGtK?= =?utf-8?B?bmFJdGl3TDZZMkE3VWNoUXQ4QXFwSEVmZWxUUksrL0doWWNhbVJ0MjFFL0ll?= =?utf-8?B?Uno3WFhRTkU2NnZORitZUHZrQXhzSFZURXBhQ05Kd1NNNzYzNk9seTN3Tkc5?= =?utf-8?B?Q2FPYnJIbzV5QXpHRU5KTXBuNmppZDJiSU1aMHpZYk5MaDRJWjFIRC9KT0lJ?= =?utf-8?B?UGk4ajl6TXZ1dXZaLzB0ZUVmRjNiYkRWTlF5VzJvUGpNUWNIYU9FVUNrZnBt?= =?utf-8?B?MG9BMUtpQTMvZEc5QnFQNGhsdExqQlZNNUZ3Z2JWejRXQ0JHYVRPclp0Nk1Y?= =?utf-8?B?Y0FoKy9EY0k2MFlza3YzazBWYUEzaEN3ekV1YUlNdWduc2hmRU84aHlPT251?= =?utf-8?B?YjdzaDJobFJDanVOaVFYUkZvMzBxNkRibDdyV2ZzaFpWR0RNeWRFbG15bUg3?= =?utf-8?B?V2xHclhEdm5BSVdSOVVoR0ZzZTIvYWJNd0xSc2pyTXV4b21DRk5DVi94Y0xi?= =?utf-8?B?NUVPaGxpVi9DeWR3UFdEWUVaam13bnVZV2JqdlpJenhsc0Rqdjk3aUxlZWgy?= =?utf-8?B?bnE3RC9LT01jbFZ6UkhGc3lham1Nb1dkYjcxcUV5V1drVUVJUFMzN3RjVDc4?= =?utf-8?B?RmJZUDZXUTZJbm5LdmRtWkU4T3FsS1crNVUreEw2cFROT01YMzRoVTd3YnBL?= =?utf-8?B?TS9YYW5PWllBZUxybGJ2dTJJS3JoWUwwMVVlbEJLSFpheFlTWmJMUE1HNWRv?= =?utf-8?B?MFdVR2QvMjZlS1NOeTg1Q08rVllQdVQ3QllmTHZKSVFGd25YR0hqTHRMTHlT?= =?utf-8?B?QzVRQXozblJJcmF5eU51OUFFUk1CTEVvM2FDZmwzWGU0TFZKeUl2dTV0MnZ1?= =?utf-8?B?S0Rremc5M2hyTjdTTXM0RG9TcHBuejlXY0gwMFpFQXJkUE9wK1lkRmMwdDZv?= =?utf-8?B?bWw2eHJpMnlKVW5rTFFmTVVyQWZSeFJOY2NuMk5jU3BZeGdrNW5QR0pBNVJQ?= =?utf-8?B?eW5heUFrWnc1b3JaeXV2bHoxSzE3TStLeTQ4a3pLUTBOYVo2NS9aZmNjaWQ3?= =?utf-8?B?eFF0SDVJQ1p1dmx1MDA4Q2p2aFpwNkk2Wm84dUtrbG5nUGZFdjIzR0RuQnZq?= =?utf-8?B?T0NYdXhxdVQrcXkyOHowQWhWQTFuTU9aM3ZQbHJkTG5wS0VtdUh1RE5xYS9O?= =?utf-8?B?a1ZlbVRPUTE1ZGFlSHR1UGttcVRERTM5ODk2K1NCaFVxSmdlMW9UTmhmUkNn?= =?utf-8?B?VGcxWkhwb0RNdmlMenl5K2FXeEV4blFzZXNxQlR2WDNQU1g2K0lSSWh1eWgz?= =?utf-8?B?OFJnTTZpeCtFYlliSlBMUXdXRDZZOEJpVm05QTZaUWt6aWNOMjlJbjJxT2tk?= =?utf-8?B?NmdCYWIyenp6OWEyYU5TZTVqbE92d1RRQ2NPMnNQV09hd2d6TGZhRUlLdTZ0?= =?utf-8?B?aGE3T0xScS9BcFhST0U0SzdhSTdUcEJDMEV4MWxVN0lOZVp2SVRtcTJKL0pN?= =?utf-8?B?NHc4SVZPWU9QVFZBazZkcnV3aWlFOENyOURkSW04b2NTK3NHRElhU1ZBN1NJ?= =?utf-8?B?Q3gvVTMrZlMzbkxTb0hZTlp6YXJ4MzVOdzRkdGgwaWRFT0FRSDJvbCtibEY4?= =?utf-8?B?UTZTeHcrK3lrQmZwbC9DcFlwMDkwZjEwTUZpakI0K2Z3VkJjSjBqeFBMeVQ5?= =?utf-8?Q?l8p0LRR8Z2uZMdIyreh24nM=3D?= X-Microsoft-Antispam-Message-Info: NnMLens5x+JdTl9sBca0kowG3vA72RB7lFnJyFJxd8XnISTT2MOGy5D8Qhm++0hMvX+yA+1SNl8hZAg2dGT2PJeGXG1gD5tMgXbMqcE0yCRFaa56daW8pS6O3tHAAq1W1ylgmnAqZcH4Wb4EVQ5kOtAJ2n/8BRdj7cS7ScgXJcQk9ATnhtdLFeA0dV097n4Z X-Microsoft-Exchange-Diagnostics: 1;DM6PR15MB2394;6:kbm1i7ks2p5w97mGijsiMDKyR+a9Z262rkdrO99NFIW0TpohyBm/PO/6dUESoN3qR3jIkijEhBQ7ytSa1BL+lZrPCHzO5t62zfuxzP6M2E8YoG3Fo1bNkJfv6TqkHdEKLHy2skJuCKAaOl6gR6uoLjhRjIikTEEd9zb8zF0XpwdvCw5f/sN/2d48QGL0U726KnvitamXzNKZdtg764IRctSnPeC1/DO0edUClOqubAD2pY8bj1tRtRkI+fbq0PzzYtLDBj9lVVhakfLTQb61h9kSsKx2nY81f8YsTFZgSUj0eOEcNpBn9ljb2sk/AOWhbIVz0kEw3XH3VlS3ROFA9k7iwZQl6dx2wge/9XJyUjtP4FNVYBKItzO3LgiLkE0+PBDsX8kmGSugOn194cN2JWE3O0EtOTXJaFibsasibPeMpEETGy1/i8W637oYjaaflyq9fsal8jSVVAbWH9Ze5g==;5:8QZ6am6VSXPmFWMkeSl9hezpwNNcALMqWZQCLX3/89bcamYFPHKd4xkBGu34Rf1pYfNclxF6NsX0zI4MtRYAygKS+uIkOK5EDL0YRDWzZK1u8LUDkOE5P4ZPHm2zOz+oRSyV91sNRGDDZ9W6DPT4jfUQoVuEChnLttGTOxOgy6I=;24:aQlbGh/puLzvO02ERLEBRCW9RU8EXxszdljOyXvfgUNJktq1Zq1BkDqNif1VZ8XAluI2TBMwz6O1x9HVgCBAzh9z3qawLWpTvYa+kPcAQuo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DM6PR15MB2394;7:A8sloeM4YRRqCEqz5AHg1DaTZy/ueHocvDEiaaP/eWmSaMBizGeFJ/OVCEJmT0PULT2liyPcBWa7+slT5yWrjYqrdTEdm6faLAgoZaM0xKhtmLN2jlrFzpJSIJTUveJLylW+V/3rmIz9qoIwmzFeaKaaxqpq6SV8XHyBSrH7bUbG7att3Gr0zqHGF94yMm1EbqQcn56gcmbN1fbPkxh/EpDINHhWs/XqLYMF/3s7H94rTsX54E8/vkmmozAkzlsE X-MS-Office365-Filtering-Correlation-Id: 8aa36b82-4e72-45ab-a832-08d5c7d2b31d X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2018 15:16:50.0543 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8aa36b82-4e72-45ab-a832-08d5c7d2b31d X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2394 X-OriginatorOrg: ericsson.com X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00020.txt.bz2 On 2018-05-31 10:46 AM, Alan Hayward wrote: > > >> On 31 May 2018, at 14:22, Simon Marchi wrote: >> >> Hi Alan, >> >> Since there is a good number of macros copied from the Linux kernel, it might be >> a good idea to isolate in their own file. It would also be good to identify >> precisely which file they come from (the path relative to the root of the linux >> repo) and the git commit you used. >> >> Also, since the copied code is rather large and non-trivial, does it pose copyright >> problems? If we want to include it, maybe that separate file should not state that >> the copyright is owned by the FSF, since it's not the case? Maybe others have >> experience with this kind of things, or maybe we should get an advice from the FSF directly. > > A new file makes sense (especially with regards to copyright). However, the plan was > to eventually remove the macros when "enough" time has passed - keeping everything > in aarch64-sve-linux-ptrace.h made it simpler than removing files. How come? Removing a file is not complicated. > Is there a minimum kernel version that gdb requires to link against in order to build? > The relevant defines are in 4.15. The kernel is now on 4.16.9. > > I’m guessing this must have come up before when other targets added new kernel features? > I didn’t want to suddenly destroy everyone’s aarch64/targetall build trees without > warning. I don't think there's a specific Linux kernel version we require to build GDB, but it's good to support as far back as possible with a reasonable effort. Since they have only been added very recently, I would keep our copy of the macros for a while, if it's not in the way of anything. >>> diff --git a/gdb/nat/aarch64-sve-linux-ptrace.c b/gdb/nat/aarch64-sve-linux-ptrace.c >>> index 9381786fda..84c7a41f40 100644 >>> --- a/gdb/nat/aarch64-sve-linux-ptrace.c >>> +++ b/gdb/nat/aarch64-sve-linux-ptrace.c >>> @@ -25,6 +25,13 @@ >>> #include "aarch64-sve-linux-ptrace.h" >>> #include "arch/aarch64.h" >>> >>> +#ifndef GDBSERVER >>> +#include "defs.h" >>> +#endif >>> +#include "regcache.h" >> >> Hmm we try not add any more "#ifdef GDBSERVER" in the common code. >> >> https://sourceware.org/gdb/wiki/Common#Header_files_in_common_code_.28defs.h_vs_server.h.2C_etc..29 >> >> Instead, we should try defining a common interface (probably in common/common-regcache.h?) that the >> common code will use, and that regcaches from GDB and GDBserver will implement. > > I tried using common-defs.h, but gdb/regcache.h requires defines from > defs.h - RequireLongest and maybe others. > Putting defs.h at the top of gdb/regcache.h then broke in a weird way. > A lot of fiddling later, and I hadn’t found a way to make it work. > > Creating common/common-regcache.h gets a bit odd because, the functions > I need for gdbserver (raw_supply, raw_collect and get_register_status) > on gdb come from: > > > class reg_buffer > ... > enum register_status get_register_status (int regnum) const; > ... > > > class readable_regcache : public reg_buffer > ... > > > class detached_regcache : public readable_regcache > ... > void raw_supply (int regnum, const void *buf); > ... > > > class regcache : public detached_regcache > ... > void raw_collect (int regnum, void *buf) const; > ... > > > I don’t think that this would work: > class regcache : public detached_regcache, common_regcache I did some quick hacking and it seems to work to have this in common/common-regcache.h struct reg_buffer_common { virtual ~reg_buffer_common () = default; virtual void raw_supply (int regnum, const void *buf) = 0; virtual void raw_collect (int regnum, void *buf) const = 0; virtual bool raw_compare (int regnum, const void *buf, int offset) const = 0; virtual register_status get_register_status (int regnum) const = 0; }; and make your code in nat/ take a pointer to reg_buffer_common. gdb's reg_buffer and gdbserver's regcache should inherit from reg_buffer_common. I built it on other regcache refactor patches I have in the pipeline, so maybe some other changes in there are needed, maybe not. I pushed the result on this branch, it's a bit raw but it should be enough to show the idea. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/simark/regcache-for-alan >> Since this returns allocated memory, could we return an RAII object? Either >> std::vector, std::unique_ptr or gdb::unique_xmalloc_ptr. > > Yes, I’ll update with one of those. Is there any documentation explaining > when to use which of these? I don't think so, if you think it would be relevant we could add it to the wiki. In short: std::vector: Allocates and manages its own memory. This is good when we allocate the space ourselves in GDB, and is especially good for buffers that need to change size over time. By default, an std::vector would zero-out the buffer on allocation. To avoid that when we don't need it, we have a specialization, gdb::byte_vector, that leaves the memory uninitialized. You could gdb::byte_vector buf (iovec.iov_len); iovec.iov_base = buf.data (); ... return buf; std::unique_ptr: It is used to wrap a pointer to something that has been allocated with "new", it will free it with "delete". You could do std::unique_ptr buf (new gdb_byte[iovec.iov_len]); iovec.iov_base = buf.get () ... return buf; gdb::unique_xmalloc_ptr: It is like std::unique_ptr, but frees the memory using xfree. It is useful to gradually add some RAII to GDB code that uses xmalloc. For new code, I would either use std::vector or std::unique_ptr. I just noticed that in the code in the current patch leaks the allocated memory if ptrace fails and we call perror_with_name. Using an object that manages memory will fix that. >> When fetching registers, won't it be usually to fill a shiny new, empty regcache? >> In that case, won't it always fall into the "if" branch? >> >> In any case, should we check the status of the VG register to make sure it's REG_VALID >> before we try to collect it? > > I thought the same regcache was used each time registers needed reading? > I’ll double check this. > Either way, yes, should probably check REG_VALID Hmm I'm not sure either. Indeed it would make sense that we re-use the same regcache. Thanks for double-checking. Thanks, Simon