From patchwork Sat Feb 27 10:21:42 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 1445157 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=bb3lhXG8; dkim-atps=neutral Received: from sourceware.org (server2.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 (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4DnjJG4Yv8z9sBJ for ; Sat, 27 Feb 2021 21:22:20 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BD45F382E835; Sat, 27 Feb 2021 10:22:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BD45F382E835 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1614421337; bh=Vifrm3Q89TiG/9egrZl+iiBAltlXJQ8lddeb10P7EZA=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=bb3lhXG8XcrTD7aXhkgbNV7tcI+h8DFwwykzKA9Xh8/QeIvYE7YcEFrkxCvYQ9nV1 2y9F5w3hYisqkzfWULTjizymhtMSTx9zTVChFQcPOyTMGgq6tECp48a31CoDn4SAlF 8h8YFbhDpkp64Fi4uBT5fjLqsIJtpU8TB+Q1InP8= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id B5A533857C52 for ; Sat, 27 Feb 2021 10:22:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B5A533857C52 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-599-hl4-XrpDNZOUqc_8Aow3qA-1; Sat, 27 Feb 2021 05:22:12 -0500 X-MC-Unique: hl4-XrpDNZOUqc_8Aow3qA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A7CAB185A0C9; Sat, 27 Feb 2021 10:22:10 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-112-197.ams2.redhat.com [10.36.112.197]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D8F3B2617F; Sat, 27 Feb 2021 10:22:09 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 11RALslo451154 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 27 Feb 2021 11:21:54 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 11RALgGj451149; Sat, 27 Feb 2021 11:21:42 +0100 Date: Sat, 27 Feb 2021 11:21:42 +0100 To: Jason Merrill Subject: [PATCH] dwarf2out: Fix -gsplit-dwarf on riscv or other non-.uleb128 targets [PR99090] Message-ID: <20210227102142.GD4020736@tucnak> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Jakub Jelinek via Gcc-patches From: Jakub Jelinek Reply-To: Jakub Jelinek Cc: Mark Wielaard , gcc-patches@gcc.gnu.org Errors-To: gcc-patches-bounces@gcc.gnu.org Sender: "Gcc-patches" Hi! As mentioned in the PR, riscv* only supports .uleb128 with constant arguments, doesn't support difference of two labels because of aggressive linker relaxations. But I bet various other targets, especially those not using GNU assembler, might suffer from the same problem. As the FIXME comment in output_loc_list indicates, we ICE on -gsplit-dwarf on those targets whenever we need .debug_loclists, because we only emit DW_LLE_startx_length which requires working .uleb128 delta of 2 code section labels. We can't use DW_LLE_base_addressx once followed by DW_LLE_offset_pair either because the latter suffers from the same issue - need .uleb128 difference of code section labels (and in that case not just for the second operand but also for the first). So, this patch implements what the comment said and emits DW_LLE_startx_endx instead, which wastes more space in .debug_addr, but will work. Bootstrapped/regtested on x86_64-linux and i686-linux and as written in the PR, Jim has tested it on riscv*linux. Ok for trunk? BTW, for HAVE_AS_LEB128 -gdwarf-5 -gsplit-dwarf, maybe we should consider instead of always emitting DW_LLE_startx_length do all the optimizations that we do for HAVE_AS_LEB128 -gdwarf-5, or at least a subset of them. For !have_multiple_function_sections, we in that case emit just DW_LLE_offset_pair (that can certainly be a win for small TUs, we wouldn't need any .debug_addr entry in that case; on the other side, just using DW_LLE_offset_pair can be harmful for very large TUs especially if the loclist has many entries, emitting in that case a single DW_LLE_base_address or for -gsplit-dwarf DW_LLE_base_addressx followed by DW_LLE_offset_pair might be much smaller), and for have_multiple_function_sections figuring out if DW_LLE_base_address followed by DW_LLE_offset_pair entries or DW_LLE_start_length is bettter. So perhaps a middle-ground for -gsplit-dwarf would be to always do the have_multiple_function_sections behavior, i.e. DW_LLE_base_addressx followed by DW_LLE_offset_pair vs. DW_LLE_startx_length decisions based on the ranges and their counts. And perhaps dwz could optimize afterwards, on linked binaries or shared libraries it knows all the offsets and could figure out optimal DW_LLE_*. 2021-02-26 Jakub Jelinek PR debug/99090 * dwarf2out.c (dw_loc_list_struct): Add end_entry member. (new_loc_list): Clear end_entry. (output_loc_list): Only use DW_LLE_startx_length for -gsplit-dwarf if HAVE_AS_LEB128, otherwise use DW_LLE_startx_endx. Fix comment typo. (index_location_lists): For dwarf_version >= 5 without HAVE_AS_LEB128, initialize also end_entry. Jakub --- gcc/dwarf2out.c.jj 2021-02-10 07:54:25.210622383 +0100 +++ gcc/dwarf2out.c 2021-02-26 19:11:19.555409473 +0100 @@ -1317,6 +1317,7 @@ typedef struct GTY(()) dw_loc_list_struc const char *begin; /* Label and addr_entry for start of range */ addr_table_entry *begin_entry; const char *end; /* Label for end of range */ + addr_table_entry *end_entry; char *ll_symbol; /* Label for beginning of location list. Only on head of list. */ char *vl_symbol; /* Label for beginning of view list. Ditto. */ @@ -10101,6 +10102,7 @@ new_loc_list (dw_loc_descr_ref expr, con retlist->begin = begin; retlist->begin_entry = NULL; retlist->end = end; + retlist->end_entry = NULL; retlist->expr = expr; retlist->section = section; retlist->vbegin = vbegin; @@ -10327,10 +10329,10 @@ output_loc_list (dw_loc_list_ref list_he if (dwarf_version >= 5) { - if (dwarf_split_debug_info) + if (dwarf_split_debug_info && HAVE_AS_LEB128) { dwarf2out_maybe_output_loclist_view_pair (curr); - /* For -gsplit-dwarf, emit DW_LLE_starx_length, which has + /* For -gsplit-dwarf, emit DW_LLE_startx_length, which has uleb128 index into .debug_addr and uleb128 length. */ dw2_asm_output_data (1, DW_LLE_startx_length, "DW_LLE_startx_length (%s)", @@ -10338,13 +10340,26 @@ output_loc_list (dw_loc_list_ref list_he dw2_asm_output_data_uleb128 (curr->begin_entry->index, "Location list range start index " "(%s)", curr->begin); - /* FIXME: This will ICE ifndef HAVE_AS_LEB128. - For that case we probably need to emit DW_LLE_startx_endx, - but we'd need 2 .debug_addr entries rather than just one. */ dw2_asm_output_delta_uleb128 (curr->end, curr->begin, "Location list length (%s)", list_head->ll_symbol); } + else if (dwarf_split_debug_info) + { + dwarf2out_maybe_output_loclist_view_pair (curr); + /* For -gsplit-dwarf without usable .uleb128 support, emit + DW_LLE_startx_endx, which has two uleb128 indexes into + .debug_addr. */ + dw2_asm_output_data (1, DW_LLE_startx_endx, + "DW_LLE_startx_endx (%s)", + list_head->ll_symbol); + dw2_asm_output_data_uleb128 (curr->begin_entry->index, + "Location list range start index " + "(%s)", curr->begin); + dw2_asm_output_data_uleb128 (curr->end_entry->index, + "Location list range end index " + "(%s)", curr->end); + } else if (!have_multiple_function_sections && HAVE_AS_LEB128) { dwarf2out_maybe_output_loclist_view_pair (curr); @@ -31288,12 +31303,14 @@ index_location_lists (dw_die_ref die) to the hash table. In the rare case of DWARF[234] >= 64KB location expression, we'll just waste unused address table entry for it. */ - if (curr->begin_entry != NULL - || skip_loc_list_entry (curr)) + if (curr->begin_entry != NULL || skip_loc_list_entry (curr)) continue; curr->begin_entry = add_addr_table_entry (xstrdup (curr->begin), ate_kind_label); + if (dwarf_version >= 5 && !HAVE_AS_LEB128) + curr->end_entry + = add_addr_table_entry (xstrdup (curr->end), ate_kind_label); } }