From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id sLfnCmam/GVmtRAAWB0awg (envelope-from ) for ; Thu, 21 Mar 2024 17:28:06 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=amd.com header.i=@amd.com header.a=rsa-sha256 header.s=selector1 header.b=wXI0qz6A; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 26CC91E0C0; Thu, 21 Mar 2024 17:28:06 -0400 (EDT) Received: from server2.sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id ACE8E1E08C for ; Thu, 21 Mar 2024 17:28:03 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 357733858C32 for ; Thu, 21 Mar 2024 21:27:53 +0000 (GMT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2077.outbound.protection.outlook.com [40.107.243.77]) by sourceware.org (Postfix) with ESMTPS id 350A73858D28 for ; Thu, 21 Mar 2024 21:27:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 350A73858D28 Authentication-Results: sourceware.org; dmarc=fail (p=quarantine dis=none) header.from=amd.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=amd.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 350A73858D28 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.243.77 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1711056450; cv=pass; b=aG9tbZG48yO9DYrsNaDH0S4BlWVX6Kmjh126qx37qX08c4yU90gqUPA7kYPzsJquJdhVECmw3qW0JN80XGsxVo+Ihjdi+/EV8gsN9xzUh+LVg4rHQwhzT9zZBQPzNbq3qx7Fseg0Tdn2k6dtotumGsj8qkXHNYxD8d6/WyTvgC0= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1711056450; c=relaxed/simple; bh=NfCFjCgeuWwtzFESP5jDSHr4anvOfggd2ska2ivCnXU=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=kInXiCpSrrqO4wHFnQdB8lMOMtYIIGsvLpAE4T8go48G8b5RS8pCBtO3BFUJjDP8jehitHdoFJwxMuWjVcsSFuRpxrfEN+rkwJmzpB/RCd0+Uro9NmMQvSFNDdnKeQ/u9kFD1ipO4bWpcUq2yaymYRHvgWq8SHSGVIBVslmbloE= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mu6Aqd9ciMvrln1MqGe/AxNMsECm+1HsCM6Q7AEsnte2nZgg5d5mscsUyhbAb1YQBfa2qQA6R6TbVc9euJ47g4d3HdFYZw5AA4zLJAZuBKZAj6wgo+EonrGlCVVpm4PYXQsK1JLZXMBwkYkwW0IgP9Fbf/i57iwJs0JCkK+HC/XT34/ZZQdxsTOUVUEFGgcbe4umPsZyFKdAFn4QVFShv4dCS+fiZO7qtI925EXpw2uqevKbqE2Hu7iUJxDuW/kzQBwONuJ0gYIiMLVP70E22vaT2BzYXJ7GuGsqU+E8TLCbzYyIYokkcOscgIxgMe6aW2uBON+deJf7qnGgxi8qdA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4yND+74GZy9wZZWH9lIfjxa7jkHlmS/I83loGf3T8wo=; b=R+xk19Ied3vEXyq5Dd63xHGNrwIaDwECe46PtBClmIsAu6Jn9f0M9yY2VedQWtQWgTZdqkptWnUZvUCfAbEh5+W4Qe7n8e01g3PaxCNu45CYkT7oVGgC+A3HYpAhqhbIhhNJE6CRHjFlnqyJl61HbPbgYkeKPRvAUZ4wLVPnTle2j9Of8c2Yc75bxGp37VCMGIDa2fRWuJRBMmyVT3RMbGTX6UHf6p9j9uvWggwA+/jmbDRzoZCY4dd9cEuXlY2zPGJp7rMXl5MzCtRRlfA0r2SR4vg5yjris7NKoeIU9iBnIKoxtUg1myvBmEvydCjL1kzQtBfRj7oDVLYKLCvvDw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4yND+74GZy9wZZWH9lIfjxa7jkHlmS/I83loGf3T8wo=; b=wXI0qz6ABCRiP/DOuA51jitZZCDWtYpnHk+NTTqJ8Js4X6ecgLqmgF5YGhqNTiZV0564ck8ljfCSD+EaATJ2wQ6fwJglcQP+znTatOZpe3rzJ3f6Nf7p5cqL4uv71yE9qxAN+Humz8s2xMUnKb8mb1cOJbY6st/CZgwAxtRykko= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from CH3PR12MB9079.namprd12.prod.outlook.com (2603:10b6:610:1a1::9) by SA1PR12MB7317.namprd12.prod.outlook.com (2603:10b6:806:2ba::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.36; Thu, 21 Mar 2024 21:27:24 +0000 Received: from CH3PR12MB9079.namprd12.prod.outlook.com ([fe80::f98e:8d91:f485:89f9]) by CH3PR12MB9079.namprd12.prod.outlook.com ([fe80::f98e:8d91:f485:89f9%3]) with mapi id 15.20.7409.022; Thu, 21 Mar 2024 21:27:24 +0000 Message-ID: <5f504bb2-75b2-43fb-b74f-708cf0c46bb6@amd.com> Date: Thu, 21 Mar 2024 21:27:19 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] Teach GDB to generate sparse core files (PR corefiles/31494) Content-Language: en-US To: Pedro Alves , gdb-patches@sourceware.org References: <20240315182705.4064062-1-pedro@palves.net> <1cb2e4f4-f14d-4434-9eb2-b33fdf4bf0bb@palves.net> <269ff31a-9aeb-4293-a4d9-df0f16f12e88@palves.net> From: Lancelot SIX In-Reply-To: <269ff31a-9aeb-4293-a4d9-df0f16f12e88@palves.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: FR4P281CA0011.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:c8::8) To CH3PR12MB9079.namprd12.prod.outlook.com (2603:10b6:610:1a1::9) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PR12MB9079:EE_|SA1PR12MB7317:EE_ X-MS-Office365-Filtering-Correlation-Id: 22a73214-6dfb-4faf-1d8f-08dc49edb31c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 8NtOzsdleZ69ReTlgQEKjdMtDrgRmzNJQuzCUpaPc8cBmOEu2WgZEbYsL98tkMA79uwSjmWY7cCgY84IbGqg1ANDVnZWccSA4WBKyCupWuW8xEaDNS2BzJ7b/UkFAtSpm88YNP7du2A6Nm3V/grSC88FTiBnSXiT8c+3P8g5qdLLG5ibLyr2Zs+XEIWRanE/r7WmuvBPROSk28bJNGfvmBCGK/velvdQuePaRa+aBvoY9ziFW5qAAb+Fta/oNTiNBrb0xzegrrkLgO2x/UvjQ+WVrT+3yggcYR3+pMqzgT6IxVCxb0Bvfg/NRasl53r3WDKr8gukzB6SC50GD8Gck8ngszzSwGThLuK3vmGOEWJ8tFc3W8XJzxRVyJLZcb7mywNU+Gcb+drLnkI9jLxuFzF/Nqa1VCeoKL3bE8zlPpeO8pvsFi6WN8g/2ARLDejz3k8FviEIihJ8iFJJsFAktYY81wDQk+ZTfGwGK6uYoBo2kgsfJObN0janQA3DVh6mnpLxBM/PeHh65V+eMQueGZNm8NW5XY2ccWoWj9pkARXnxQPzhi9hWa4hjRkOsSZNbyNJt2vUoUFsKPKPzxLbpe9hbE7SejERAG6BMb4raYm5dulkJXudMMrrLmKV3XH8ryc5nacTmI5hXqvBJ95hJYQwmOt7S41UuY+HR735/Ks= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH3PR12MB9079.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376005)(1800799015)(366007); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?K2U0NEtDd2VWdmFQcStHR3BWeFRpR2VLVmRUdkVRbG5ObGRacFNsM2U5ZW5q?= =?utf-8?B?K3VKY3J1cE5UZEtsaTl3cjFpb2lVeVlxMlBwMjdCbUovMEQrbHZmZm9LSkNZ?= =?utf-8?B?VTd3aEpSeE5SWm9xRVFyUjVPZW1ydjVVVms2MDd4dTd1UUh4OUF5dmNaMmpi?= =?utf-8?B?cG9MR29lclRzdXFFM3ppdDNkWGs1UWRpR3pXTHNMQWVIQmpYemxuOVFkR3NB?= =?utf-8?B?NGpUSS9yVEg5SlQ3S1dTREFNTTQ5VnZNNERac0ZOUHhaMCt2aFhibEFDdVV4?= =?utf-8?B?Z0dpWCtJbGZRcnQ5eVhOdTFyS2VQbEJXWlRVc211N3lNZHlMa0pCZ0FNOEVU?= =?utf-8?B?YjBYQi9uVnJuZWxpRTRUVHNzWW1yTFRRZHZaNk5UanI2SHBsVktKQ1VDaHIz?= =?utf-8?B?UUFRQjkwdmNBRmJLNWgxQTI4bnVxNE1sa2VEaHYxN3hzeEFIZTczWlptdzcr?= =?utf-8?B?eWxYZnJMS0l6eUNiemF4bTRoZmNjQ3QxUlk5S3Z5K2tibVR0YUtsNmUzclpR?= =?utf-8?B?aVJzbXVkOER5TzFYVnBVQ05JQjFvTjdzdE01US9OcERRcSt4YXhUMkVFOWlV?= =?utf-8?B?OXFRaFNBd2dSanBhNXRkbEpaTnRZQlF2WU4zOWRWTnJRUHVpOGFYUFdmNkhl?= =?utf-8?B?WFQvMmd3cXIrUnlDWHBkT3NKUjhrRTc2bUJQUk1VaHVSMGU1c2psVEdFVXdS?= =?utf-8?B?ZU1OYlYyZUh3LzZkaVJPMGNFdFJaZTFhODlSRTVHQmxsMm9ZN01lSFViWUlC?= =?utf-8?B?ajRUdDlISllIUU5UZnRSOWVqMjkrTCs3U3VENmRTMHJNRWNpcEV1dDZrN3JX?= =?utf-8?B?aFBzWUxTTkcvOUNtaEd4QWU1QnIzQVA5QkYxbEhoRXNxTExyRy9wTTgrUjQ4?= =?utf-8?B?YXNLYnFYMUNKNFdmdDU5cjNQWlArN3hrVG9wVEhHVS9RajhaaDQ0OFJjQ29F?= =?utf-8?B?aUZ0ZElDT3lLQmVudlNOM3d0ZWVHUmhVVURlMGsxMnZOUzVsNGt5ZmM0Njh2?= =?utf-8?B?elNlT1ZvbWIrckpxR051K2w0cFVUbjRrUW54VEFtTlN0b0d5MTJQZHE5aWVK?= =?utf-8?B?L0dDYlFQdVlnaUdMU3VtOEZDTDl3T2lzT05DRkovOFJMME1kTjdKWEsxWXBD?= =?utf-8?B?NkVsSTk5V0tDVHpSdjM3NDAycE1DekgyN1Y1aHdidmQ3Ui9Kd2pIeU84bWRs?= =?utf-8?B?QXJpdTdWYkx6OEFLZXFyc3BrbWhNUzdsdmJHT1FlZ3N2OXMreGtOd2JKdUtV?= =?utf-8?B?OWNuMzloWXJQUUY4Nko1eUNTYzBucE15UXNhQjVUamZMS3Z1SWVaQ3ptL2dX?= =?utf-8?B?SE5SNlJ0SlBkY1A1ZWp6ZUxrUDBQb0djQUZqanJrZmdQNVhpdlNGVGJhQWJi?= =?utf-8?B?U3NMLzAvRWdud3BxVWZaa3ZyNjhwb2haQm1WVFp0OWJ3Q2V5U0NkTXZZRzFx?= =?utf-8?B?eGI2NVBsQzJ2b0owSVhlMUJPSmVnQVgvbzlqVXN3U2VySjdIZ20ySVh5dW51?= =?utf-8?B?bTR0TjM3VERZYUtZN1h0NHMxOUIwVHZjRm1NbGd2OVJ3VzE5MmFOQlhEb1dv?= =?utf-8?B?c0lseWtUZTdsRk44RzNKTEhFeWM5bXBHQU10TGJURWN1Y0U3VWV0L1ZxNWxJ?= =?utf-8?B?MlphSlpmM0FHQmZZem5laXZGMVdLbzc3K2c3V0tObXEvVWNob3NGWTVWM1g4?= =?utf-8?B?OG5ETlplaG90djByMUdTL0FWZitic3hQemI5b3AxbUhuWld4NHJDak45RGZv?= =?utf-8?B?SzdCRG92NVV0OGdEeEY1YmRXd0lOQm92ZVVCTlRqYXBVdUdCNU1GS0ppc3Vt?= =?utf-8?B?SHlCZHkzQThoU25nVTFtWVJ1VWtIL2dyNm1iWmdsMnF0aWhVa3JhNzVyaStW?= =?utf-8?B?c2FXalBhdHB0Q3piYmphekdPUWpVaXRFYmZJMFhmeVlBemxQdnUxdGV2NXZG?= =?utf-8?B?T2NYWjVwZXhNY1VkaU13Zk9vWlh1Q2tlaStSSC9MM3JiYklUMDZxYU5icVd2?= =?utf-8?B?QWUydHNVUUgxTXlrV08zTi9qWXRmY3BoUzF4SitVVVRUK0dKeXNUMCtQNzhD?= =?utf-8?B?MVhENnZBaW9lWkNHVm9RZ1R4b0diTVhRQ0ZRMHR3WFg0aXdFRWpIMjJ0ZVg2?= =?utf-8?Q?8RckPN6VgZBGZSNBLY5lxd/rK?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 22a73214-6dfb-4faf-1d8f-08dc49edb31c X-MS-Exchange-CrossTenant-AuthSource: CH3PR12MB9079.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2024 21:27:24.3086 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: MWlCmmrEOOkojMo7T1aMqgD5uECAvzI3C59y1UJyRowkHObgdvPqeN6LubjEWUyD/pqu6Jq3phrim/WKmG2JzA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB7317 X-Spam-Status: No, score=-10.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FORGED_SPF_HELO, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Hi, I have a couple of small comments below. On 18/03/2024 17:43, Pedro Alves wrote: > diff --git a/gdb/gcore.c b/gdb/gcore.c > @@ -567,6 +583,158 @@ objfile_find_memory_regions (struct target_ops *self, > return 0; > } > > +/* Check if we have a block full of zeros at DATA within the [DATA, > + DATA+SIZE) buffer. Returns the size of the all-zero block found. > + Returns at most the minimum between SIZE and SPARSE_BLOCK_SIZE. */ > + > +static size_t > +get_all_zero_block_size (const gdb_byte *data, size_t size) > +{ > + size = std::min (size, (size_t) SPARSE_BLOCK_SIZE); > + > + /* A memcmp of a whole block is much faster than a simple for loop. > + This makes a big difference, as with a for loop, this code would > + dominate the performance and result in doubling the time to > + generate a core, at the time of writing. With an optimized > + memcmp, this doesn't even show up in the perf trace. */ > + static const gdb_byte all_zero_block[SPARSE_BLOCK_SIZE] = {}; > + if (memcmp (data, all_zero_block, size) == 0) > + return size; > + return 0; > +} > + > +/* Basically a named-elements pair, used as return type of > + find_next_all_zero_block. */ > + > +struct offset_and_size > +{ > + size_t offset; > + size_t size; > +}; > + > +/* Find the next all-zero block at DATA+OFFSET within the [DATA, > + DATA+SIZE) buffer. Returns the offset and the size of the all-zero > + block if found, or zero if not found. */ > + > +static offset_and_size > +find_next_all_zero_block (const gdb_byte *data, size_t offset, size_t size) > +{ > + for (; offset < size; offset += SPARSE_BLOCK_SIZE) > + { > + size_t zero_block_size > + = get_all_zero_block_size (data + offset, size - offset); > + if (zero_block_size != 0) > + return {offset, zero_block_size}; > + } > + return {0, 0}; > +} > + > +/* Wrapper around bfd_set_section_contents that avoids writing > + all-zero blocks to disk, so we create a sparse core file. > + SKIP_ALIGN is a recursion helper -- if true, we'll skip aligning > + the file position to SPARSE_BLOCK_SIZE. */ > + > +static bool > +sparse_bfd_set_section_contents (bfd *obfd, asection *osec, > + const gdb_byte *data, > + size_t sec_offset, > + size_t size, > + bool skip_align = false) > +{ > + /* Note, we don't have to have special handling for the case of the > + last memory region ending with zeros, because our caller always > + writes out the note section after the memory/load sections. If > + it didn't, we'd have to seek+write the last byte to make the file > + size correct. (Or add an ftruncate abstraction to bfd and call > + that.) */ > + > + if (!skip_align) > + { > + /* Align the all-zero block search with SPARSE_BLOCK_SIZE, to > + better align with filesystem blocks. If we find we're > + misaligned, then write/skip the bytes needed to make us > + aligned. We do that with (one level) recursion. */ > + > + /* We need to know the section's file offset on disk. We can > + only look at it after the bfd's 'output_has_begun' flag has > + been set, as bfd hasn't computed the file offsets > + otherwise. */ > + if (!obfd->output_has_begun) > + { > + gdb_byte dummy = 0; > + > + /* A write forces BFD to compute the bfd's section file > + positions. Zero size works for that too. */ > + if (!bfd_set_section_contents (obfd, osec, &dummy, 0, 0)) > + return false; > + > + gdb_assert (obfd->output_has_begun); > + } > + > + /* How much we need to write/skip in order to find the next > + SPARSE_BLOCK_SIZE filepos-aligned block. */ > + size_t align_remainder > + = (SPARSE_BLOCK_SIZE > + - (osec->filepos + sec_offset) % SPARSE_BLOCK_SIZE); > + > + /* How much we'll actually write in the recursion call. */ > + size_t align_write_size = std::min (size, align_remainder); > + > + if (align_write_size != 0) I think at this point align_write_size can be SPARSE_BLOCK_SIZE (i.e. sec_offset lands at a SPARSE_BLOCK_SIZE boundary in the underlying filesystem). If that's the case, and data+sec_offset starts with block of 0s, you'll write it to disk needlessly. Not a big deal, but I'd go for: if (align_write_size % SPARSE_BLOCK_SIZE != 0) > + { > + /* Recurse, skipping the alignment code. */ > + if (!sparse_bfd_set_section_contents (obfd, osec, data, > + sec_offset, > + align_write_size, true)) > + return false; > + > + /* Skip over what we've written, and proceed with > + assumes-aligned logic. */ > + data += align_write_size; > + sec_offset += align_write_size; > + size -= align_write_size; > + } > + } > + > + size_t data_offset = 0; Just because that got me to think while reading, having the first part of the procedure update data/sec_offset/size and the second part of the procedure update data_offset seems a bit inconsistent. I would probably move the declaration of data_offset at the very begining of the procedure update it consistently: size_t data_offset = 0; if (!skip_align) { […] if (align_write_size % SPARSE_BLOCK_SIZE != 0) { […] data_offset += align_write_size; } } while (data_offset < size) […] > + while (data_offset < size) > + { > + size_t all_zero_block_size > + = get_all_zero_block_size (data + data_offset, size - data_offset); > + if (all_zero_block_size != 0) > + data_offset += all_zero_block_size; > + else > + { > + /* We have some non-zero data to write to file. Find the > + next all-zero block within the data, and only write up to > + it. */ > + > + offset_and_size next_all_zero_block > + = find_next_all_zero_block (data, > + data_offset + SPARSE_BLOCK_SIZE, > + size); > + size_t next_data_offset = (next_all_zero_block.offset == 0 > + ? size > + : next_all_zero_block.offset); > + > + if (!bfd_set_section_contents (obfd, osec, data + data_offset, > + sec_offset + data_offset, > + next_data_offset - data_offset)) > + return false; > + > + data_offset = next_data_offset; > + > + /* If we already know we have an all-zero block at the next > + offset, we can skip calling get_all_zero_block_size for > + it again. */ > + if (next_all_zero_block.offset != 0) > + data_offset += next_all_zero_block.size; > + } > + } > + > + return true; > +} > + > static void > gcore_copy_callback (bfd *obfd, asection *osec) > { > @@ -599,8 +767,9 @@ gcore_copy_callback (bfd *obfd, asection *osec) > bfd_section_vma (osec))); > break; > } > - if (!bfd_set_section_contents (obfd, osec, memhunk.data (), > - offset, size)) > + > + if (!sparse_bfd_set_section_contents (obfd, osec, memhunk.data (), > + offset, size)) > { > warning (_("Failed to write corefile contents (%s)."), > bfd_errmsg (bfd_get_error ())); Best, Lancelot.