From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from de-smtp-delivery-102.mimecast.com (de-smtp-delivery-102.mimecast.com [194.104.109.102]) by sourceware.org (Postfix) with ESMTPS id 378FF3856264 for ; Fri, 3 Jun 2022 12:04:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 378FF3856264 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05lp2104.outbound.protection.outlook.com [104.47.17.104]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id de-mta-41--a7sbQfsNqOS10f0uw-5ng-1; Fri, 03 Jun 2022 14:04:28 +0200 X-MC-Unique: -a7sbQfsNqOS10f0uw-5ng-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EriHtoBdTANot7xWzyYSeF0UwPDKeDkufpZY70yIiU0WyKZYy2yTs3i8twHb7lArhs8nJ5zVZH7sanUQs6/Rad95l3UF9ymeDFVWdfWlPpyy8pX8ufwGfaKISSOc6oMfUG6LMEclegZbqpwE3YMiW9f+Q5uZ1zKBVf7RmViU9N9RBwzymoOLAzmG9RzW0fbUJWU1Vuw30RGzFN+JMTNmFCeYDsLijAlEA4+KV35t9k3aY/zAthktcz5SNOBK/Zsl/71L2EARG3Bkkd56pdQrlPrgIQjpaixuRZOsmBeUBF2OkFvQaqOcKMs4sBoH2o+55dmxW5oBdyVoa+jOQ2a3vw== 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=5D6EI+8IO+VSp2NBRcn5CakRVQLpygIV24o+Tk83bhU=; b=i+gyzw1fbSB1ef0xoNT+Wwrx3JXCPcn5br+C+b88xvpKeSUnE4B/jQXHl7zsmL8GivrtnRuC0HXYbdkGI4pud6sJynMnZe8ExlpJiwBSGm2nSsTSKVUXhRlrWJlJNNKM7cWz3EEA9ZMfYDIvCVsRaQRY2mtkp0/fd3zzMWWUDlvZkfgndzbyHEs3c/hWl1VEPC2ZnXgyloVGuU9+yYUQWdIfF1TDJxtNpuiXuaB6Y1Y0Mr5aHlS4G4TLzQkIu3yOeBTxNCOO9GXQ67ddr8Y03BwjOhLYS81N7OeEtFJVmEe8BcSZ7Bsl77Flbonpg6sFAwfhgwcFxqsYlYxmcw7okw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none Received: from AM6PR04MB6551.eurprd04.prod.outlook.com (2603:10a6:20b:fa::20) by DB8PR04MB6985.eurprd04.prod.outlook.com (2603:10a6:10:11e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.15; Fri, 3 Jun 2022 12:04:27 +0000 Received: from AM6PR04MB6551.eurprd04.prod.outlook.com ([fe80::7577:8567:33c7:685b]) by AM6PR04MB6551.eurprd04.prod.outlook.com ([fe80::7577:8567:33c7:685b%5]) with mapi id 15.20.5314.013; Fri, 3 Jun 2022 12:04:27 +0000 Message-ID: Date: Fri, 3 Jun 2022 14:04:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH] Binutils support for split-dwarf and dwarf-5 Content-Language: en-US To: "Kumar N, Bhuvanendra" Cc: "George, Jini Susan" , "Natarajan, Kavitha" , "binutils@sourceware.org" References: From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM5PR0202CA0007.eurprd02.prod.outlook.com (2603:10a6:203:69::17) To AM6PR04MB6551.eurprd04.prod.outlook.com (2603:10a6:20b:fa::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4d82dd4b-ed58-48e6-fb30-08da4559352c X-MS-TrafficTypeDiagnostic: DB8PR04MB6985:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: nybS9LSgXcda54okNtfl+v1551KUcchPD/tXkmSzTg/q9JRyju0xnzW+UTjprko+rj3ve2ncc5hXJ0RXHQbpLB4qTZej/vtCORWPTgu6O6yoKQk8zl72tc5QorPx8fLTiTRgxdRtXd//sMR9Ytkv5P3Nz2YkaIB0csI+ld5kOW8QinmvfY3cwd7bsTPMiPjyWS5BjvKLAaTC8p5LrbfStkKJCyJMP1agHALSKQLLERBy/OfOMXnWs7hel5UCG4Ica4AJnfM9/H3nqGCX3EPQY2v7cYG6WlpwD5x6W/fHW1s6QnkWjDBpQbg1UzZhXXcbToUD0AC/7NxM1I26gsIOCfHtTb6NQYtxS74M+1JQExIOYY4DYqFKpkvPawYuwfKYolWR08vcBHkl1KFFdW8+wRreZKva8RF22hiKU979+DRqzdBFdSPJxupltqLXFB+/xLDMs7HAieH/oKdFG7GUxSpEQoIpy6mtX2Eq3FqgnXdbkKCG3OO2aECz9H4zVXF2fNSVZdCxZ9Wj7cArdHbP7VzZUNxv85TzkVnDKXy8JIDwrY3b3GK0G8PCEQoSvgzDLWbmF9IpsFpvVFDNxCJYHAgAWepZkoHutK/O35GRJZyXx23n7u6QHpqvHherL+LeXgKFiUkMyupw9LG4dCTrbI8VDZd63bkF1vZQb99hK768PQKlmWT0eJKLO4MoyMGkLysB9EkU8gSjWdvGemQs8QX4AJ3H403Nv6Xrn3oXxEU= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR04MB6551.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(15843345004)(83380400001)(26005)(6512007)(38100700002)(4326008)(31686004)(316002)(6916009)(66556008)(66476007)(8676002)(66946007)(36756003)(2616005)(54906003)(6486002)(5660300002)(508600001)(8936002)(53546011)(86362001)(31696002)(6506007)(2906002)(186003)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QjFvZHN0b2FMdGRLa2Jjc1hRdFFnV3FmUmlHb1NQZlFMeWV6M0p0c3p6NklF?= =?utf-8?B?S0hPRVNyV2VIdXJzTHBiYUFiVFhoV0NjMW5qNWdwT1JEZ0xGZTRHaEh2TkVI?= =?utf-8?B?U1p5K2pxczdaTzgrR3k4cVNxdzl0empjYkhYd2F0TkVaTEdIVmxvZWUzQ3Vx?= =?utf-8?B?WnJ5UGRzdjJIQTJHdS9XWXBQaGVROVUrVkhTZktBNENpdElrSll6SFl5ZjBQ?= =?utf-8?B?NTliWWhhQjlQZ2FmM0dxeVVsV2hZNndVZUpnc09KdU5zVXZjNzNOYmY0cXJH?= =?utf-8?B?REdWT3A3VmswWldFSkF5WVhVeEFVbWZ0MFRVVUorWERxK0swMHV0VndJbTlL?= =?utf-8?B?SnZxTVhpSDJtcWJBZnEwZUxKL3E0eHFUTmdNUE1GdjVNMHFIYjFJTitPY05E?= =?utf-8?B?bUNYVHJleEdiODVzYnhkSDk2UWFVNXh5bFZnRFBlYngydWlLTE9TYkwyaDhm?= =?utf-8?B?bFZRVThrbitDc0VIcUZ6M0t6TWJDQ2R3eVdPY0JjcFBqNyt2amZXSkRnNXpO?= =?utf-8?B?ZE9aMEhYaWJwSnZSZ3E4QzlTSU9kNDVaTDVlUHJKSEduQVROQWZzMllIZ3Qv?= =?utf-8?B?QS9aTmVwdy8rN09nRTN4RjcxTWpXc0hPb3RYYUpkWW83UGpoenNmRXQyTkxT?= =?utf-8?B?KzR5SGxrZW1jc3RiaHJJNmRDaUUvZERxSXBFWFc5dklwVW9jeHkyZmlidUFR?= =?utf-8?B?NFZ5cXAvMm5uM2RVZ1ZRS1lCRlBVbWVHYnlEMmpGc2RMS2xBUlBGWW41Y09z?= =?utf-8?B?U05PWGQ3Y2FuQ1BkWWpVK1hYYUNVVHlsZ3d2U3dKQnRyeTJwZzV5Z25QSHhO?= =?utf-8?B?VVE3R3NzQ3BrQWdxWVlnSkh6alhlOUxYdWo0dE13bmc1NUpWcEFtR3A5RkZP?= =?utf-8?B?VjNodzdTcWdxVUp1Y2xWR0R4bEpnclpxcUZpdm8veXBBcXRLQXJHZHZLem5U?= =?utf-8?B?TUZ0VDU1QTBDN1JBRDAvNmdSNHkwK2trcEhDMk85WkFTa0ZYRXZaWG5kMkdD?= =?utf-8?B?ZWh5WlZGdGs0YWY5czdQSks0ZWJYZldUVFpVRi9XUkpoS3c2TmpjazhUTGdw?= =?utf-8?B?NGVLT1hTN29MM0p0S1EzNHVMZkFNRmgwZU13T3duTzlQU0xjVjBnb1NCMmVv?= =?utf-8?B?eXIvUU43L1lvbHpXSjRoVlRnVzVHOEh3R1c4ck4xQU8rQUUvUGpMMzl4Y0JH?= =?utf-8?B?b0l1a1c5MTZML1VJSi8rYTcrWXlNallIOVoxR1NYNi9TQkRIeUlZWkx1eFRM?= =?utf-8?B?Uk0wbUtScnFzWmFva3J6K0h6T2VjM2hocmx3c2NGSk80NGNkcHZBWnBVZ05W?= =?utf-8?B?UzhvUFhSbUhLR0xKNHRoREhSQi9uQ0Ezc2F6ci9Tb3Z2L2ttQVF6SXByMGRt?= =?utf-8?B?N20zaGUxd1JSNy81MFdLV3hyZEk1THF1T1RDcW5CYnArZUNjNWM5TWgvYlpB?= =?utf-8?B?OUVPK0lVbU5UeU9pY3Y1NHB6TlJEd0hiY1pCYURETjhxUnZSVHppRVhrOVFO?= =?utf-8?B?enQ2S0I2T1dLUmdkSUhPTUxRNEp1UWlDNjM1VXg4c3ZDc0xUSm1sMXRZc0g3?= =?utf-8?B?Q2JXMEFHKy9xOWwvcWtzRTROMnJQdU4xRTRQTUhTTitjZ0MrTk9tc2ZYZFNX?= =?utf-8?B?YnBTWUZkT2lJRzZIZmxjelk4ZVREb2dhV3oxRzU4eDhBaFVoeFdyUUpmTkpO?= =?utf-8?B?Z1kxZkZhblZDbnZYbmw0YXd2SDRGQnBmKzlQTVJxT2p3QmRVWVhvTE9HdjVn?= =?utf-8?B?eUlJTnpOelRUYUZBZW91cUFiWXAvZm1LSW83RUE5SThRKzJnVkljR1FaOCs4?= =?utf-8?B?VEEwRzN0bFRzNlp3akcxaFRzMHMzV2h4aGVLQkdjSnBlTVE3aDR2T2Z3RTF6?= =?utf-8?B?ZzdEdEhvM3ZGakkvU084S0Y0VmllN2ZocDJpUklZaFgwamlTUktHY1Fac010?= =?utf-8?B?NUg4V05RZ01UbVI2ZS9aMFNKenlYUGlQV1pJWUJYQ3NXdHJ3bUhIb0RLRkpj?= =?utf-8?B?ekhMYUF3NktiLytGTjUxZ0xtU25RTERUZTdDRE9hVTE1MWc2SEx2dlFkRkx0?= =?utf-8?B?Y1gvSUNLRlMwRWp1WFg2QWpERVlTb0tPL1VmUUVDRmNyUnFJNjFQTWlmTGpB?= =?utf-8?B?N2UvMzVyMEh1QkFoRThDaDJxemcrNFROUHZjdEFvd1E2cHJjTk1mdHR0N2Rw?= =?utf-8?B?Y1EvdzVTY2VVZ3FHSTZLTC9lQXFsRVU4L0k2V1NlRGp2UzdJUUNaZCtmNWhm?= =?utf-8?B?TzBoMEZUY0xwZld3K2Zkd3BYaUxBWVN5ZGJyNWpseE5RWXY0anZFcDVSQ1ly?= =?utf-8?B?ay9hemhDSDVCWjAvSHdmTmhUaFVHYWh5VG9xMkVrV1ltMXZsaFRYQT09?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4d82dd4b-ed58-48e6-fb30-08da4559352c X-MS-Exchange-CrossTenant-AuthSource: AM6PR04MB6551.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2022 12:04:27.4298 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: qymg5Y6tsjGAkbJELR1j22eM40r/ocASUQJqPZ7uA2wnxRMmhlaAX0uDTJOv24ybasQyh8qM89XJj0+Nj6SJyg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR04MB6985 X-Spam-Status: No, score=-3031.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2022 12:04:33 -0000 On 02.06.2022 16:55, Kumar N, Bhuvanendra via Binutils wrote: > Patch 1/2 inlined: > > From 1bda1e144f43d1f41fe30a934ba008561083dc07 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?=E2=80=9Cbhkumarn=E2=80=9D?= Bhuvanendra.KumarN@amd.com > Date: Thu, 2 Jun 2022 17:44:02 +0530 > Subject: [PATCH] [PATCH 1/2] Binutils support for split-dwarf and dwarf-5. > > This fix adds support for split-dwarf and dwarf5, for both gcc and clang. > There are 2 patches. Basic sections dump like .debug_info.dwo, > .debug_abbrev.dwo, .debug_str.dwo etc are supported in this patch 1/2. > But location list and ranges list sections dump with split-dwarf and dwarf5 > are supported in the next patch 2/2. Just as a remark: "patch 1/2" and "next patch" and alike aren't very meaningful in commit messages. The individual commits may end up far apart in the repo. > --- a/binutils/dwarf.c > +++ b/binutils/dwarf.c > @@ -118,6 +118,8 @@ int dwarf_cutoff_level = -1; > unsigned long dwarf_start_die; > int dwarf_check = 0; > +static dwarf_vma str_offsets_base = 0; > +#define DEBUG_STR_OFFSETS_HEADER_LEN 8 Aiui 8 is correct for 32-bit Dwarf, but 16 would need using for 64-bit. > @@ -2485,6 +2487,8 @@ read_and_display_attr_value (unsigned long attribute, > case DW_FORM_GNU_ref_alt: > case DW_FORM_GNU_strp_alt: > SAFE_BYTE_GET_AND_INC (uvalue, data, offset_size, end); > + if (attribute == DW_AT_str_offsets_base) > + str_offsets_base = uvalue - DEBUG_STR_OFFSETS_HEADER_LEN; Can this legitimately be stored in a static variable? Don't you need to collect the value(s) into debug_info_p just like is done for DW_AT_loclists_base? > @@ -11889,6 +11895,7 @@ load_separate_debug_files (void * file, const char * filename) > && load_debug_section (abbrev, file) > && load_debug_section (info, file)) > { > + load_debug_section (str_index, file); What if this fails? Immediately preceding load_debug_section() uses have their return values checked. > --- /dev/null > +++ b/binutils/testsuite/binutils-all/dwo_5.s > @@ -0,0 +1,257 @@ > + .file "a.c" > + .text > +.Ltext0: > + .globl a > + .type a, @function > +a: > +.LFB0: > + .file 1 "a.c" > + .loc 1 1 13 > + .cfi_startproc > + pushq %rbp > + .cfi_def_cfa_offset 16 > + .cfi_offset 6, -16 > + movq %rsp, %rbp > + .cfi_def_cfa_register 6 > + .loc 1 1 22 > + movl $111, %eax > + .loc 1 1 1 > + popq %rbp > + .cfi_def_cfa 7, 8 > + ret > + .cfi_endproc > +.LFE0: > + .size a, .-a > +.Letext0: > + .section .debug_addr,"",@progbits > + .long 0xc > + .value 0x5 > + .byte 0x8 > + .byte 0 > +.Ldebug_addr0: > + .quad .LFB0 > + .section .debug_info.dwo,"e",@progbits > +.Ldebug_info0: > + .long 0x35 > + .value 0x5 > + .byte 0x5 > + .byte 0x8 > + .long .Ldebug_abbrev0 > + .byte 0x46 > + .byte 0x1c > + .byte 0xf1 > + .byte 0xfb > + .byte 0xe5 > + .byte 0x96 > + .byte 0x7d > + .byte 0x2b > + .uleb128 0x1 > + .uleb128 0x1 > + .byte 0x1d > + .string "a.c" > + .uleb128 0 > + .uleb128 0x2 > + .string "a" > + .byte 0x1 > + .byte 0x1 > + .byte 0x5 > + .long 0x31 > + .uleb128 0 > + .quad .LFE0-.LFB0 > + .uleb128 0x1 > + .byte 0x9c > + .uleb128 0x3 > + .byte 0x4 > + .byte 0x5 > + .string "int" > + .byte 0 > + .section .debug_info,"",@progbits > +.Lskeleton_debug_info0: > + .long 0x31 > + .value 0x5 > + .byte 0x4 > + .byte 0x8 > + .long .Lskeleton_debug_abbrev0 > + .byte 0x46 > + .byte 0x1c > + .byte 0xf1 > + .byte 0xfb > + .byte 0xe5 > + .byte 0x96 > + .byte 0x7d > + .byte 0x2b > + .uleb128 0x1 > + .quad .Ltext0 > + .quad .Letext0-.Ltext0 > + .long .Ldebug_line0 > + .long .LASF0 > + .long .LASF1 > + .long .Ldebug_addr0 > + .section .debug_abbrev,"",@progbits > +.Lskeleton_debug_abbrev0: > + .uleb128 0x1 > + .uleb128 0x4a > + .byte 0 > + .uleb128 0x11 > + .uleb128 0x1 > + .uleb128 0x12 > + .uleb128 0x7 > + .uleb128 0x10 > + .uleb128 0x17 > + .uleb128 0x76 > + .uleb128 0xe > + .uleb128 0x1b > + .uleb128 0xe > + .uleb128 0x2134 > + .uleb128 0x19 > + .uleb128 0x73 > + .uleb128 0x17 > + .byte 0 > + .byte 0 > + .byte 0 > + .section .debug_abbrev.dwo,"e",@progbits > +.Ldebug_abbrev0: > + .uleb128 0x1 > + .uleb128 0x11 > + .byte 0x1 > + .uleb128 0x25 > + .uleb128 0x1a > + .uleb128 0x13 > + .uleb128 0xb > + .uleb128 0x3 > + .uleb128 0x8 > + .uleb128 0x1b > + .uleb128 0x1a > + .byte 0 > + .byte 0 > + .uleb128 0x2 > + .uleb128 0x2e > + .byte 0 > + .uleb128 0x3f > + .uleb128 0x19 > + .uleb128 0x3 > + .uleb128 0x8 > + .uleb128 0x3a > + .uleb128 0xb > + .uleb128 0x3b > + .uleb128 0xb > + .uleb128 0x39 > + .uleb128 0xb > + .uleb128 0x27 > + .uleb128 0x19 > + .uleb128 0x49 > + .uleb128 0x13 > + .uleb128 0x11 > + .uleb128 0x1b > + .uleb128 0x12 > + .uleb128 0x7 > + .uleb128 0x40 > + .uleb128 0x18 > + .uleb128 0x7a > + .uleb128 0x19 > + .byte 0 > + .byte 0 > + .uleb128 0x3 > + .uleb128 0x24 > + .byte 0 > + .uleb128 0xb > + .uleb128 0xb > + .uleb128 0x3e > + .uleb128 0xb > + .uleb128 0x3 > + .uleb128 0x8 > + .byte 0 > + .byte 0 > + .byte 0 > + .section .debug_gnu_pubnames,"",@progbits > + .long 0x15 > + .value 0x2 > + .long .Lskeleton_debug_info0 > + .long 0x39 > + .long 0x1c > + .byte 0x30 > + .string "a" > + .long 0 > + .section .debug_gnu_pubtypes,"",@progbits > + .long 0x17 > + .value 0x2 > + .long .Lskeleton_debug_info0 > + .long 0x39 > + .long 0x31 > + .byte 0x90 > + .string "int" > + .long 0 > + .section .debug_aranges,"",@progbits > + .long 0x2c > + .value 0x2 > + .long .Lskeleton_debug_info0 > + .byte 0x8 > + .byte 0 > + .value 0 > + .value 0 > + .quad .Ltext0 > + .quad .Letext0-.Ltext0 > + .quad 0 > + .quad 0 > + .section .debug_line,"",@progbits > +.Ldebug_line0: > + .section .debug_line.dwo,"e",@progbits > +.Lskeleton_debug_line0: > + .long .LELT0-.LSLT0 > +.LSLT0: > + .value 0x5 > + .byte 0x8 > + .byte 0 > + .long .LELTP0-.LASLTP0 > +.LASLTP0: > + .byte 0x1 > + .byte 0x1 > + .byte 0x1 > + .byte 0xf6 > + .byte 0xf2 > + .byte 0xd > + .byte 0 > + .byte 0x1 > + .byte 0x1 > + .byte 0x1 > + .byte 0x1 > + .byte 0 > + .byte 0 > + .byte 0 > + .byte 0x1 > + .byte 0 > + .byte 0 > + .byte 0x1 > + .byte 0x1 > + .uleb128 0x1 > + .uleb128 0x8 > + .uleb128 0x1 > + .string "/tmp" > + .byte 0x2 > + .uleb128 0x1 > + .uleb128 0x8 > + .uleb128 0x2 > + .uleb128 0xb > + .uleb128 0x2 > + .string "a.c" > + .byte 0 > + .string "a.c" > + .byte 0 > +.LELTP0: > +.LELT0: > + .section .debug_str,"MS",@progbits,1 > +.LASF1: > + .string "/tmp" > +.LASF0: > + .string "a.dwo" > + .section .debug_str_offsets.dwo,"e",@progbits > + .long 0xc > + .value 0x5 > + .value 0 > + .long 0 > + .long 0x5 > + .section .debug_str.dwo,"e",@progbits > + .string "/tmp" > + .string "GNU C17 10.0.0 20190813 (experimental) -mtune=generic -march=x86-64 -gdwarf-5 -gsplit-dwarf" > + .ident "GCC: (GNU) 10.0.0 20190813 (experimental)" > + .section .note.GNU-stack,"",@progbits I'm a little worried about the maintainability (and reviewability) of such testcases: This looks to be compiler output, even with non- essential pieces left in. That's fine in principle, but without any comments it's close to unreadable. Plus it's then unclear whether the compiler-generated directives are actually all correct; after all compilers can also have bugs, and the compiler used wasn't even a released version, and even quite early a major-10 version. Jan