From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 5649A394504C for ; Tue, 1 Dec 2020 11:15:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5649A394504C 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-461-r-jWRpNPMrulKBXlnzDclw-1; Tue, 01 Dec 2020 06:15:47 -0500 X-MC-Unique: r-jWRpNPMrulKBXlnzDclw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 46B4AAFA81; Tue, 1 Dec 2020 11:15:46 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-113-127.ams2.redhat.com [10.36.113.127]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B23625C1A3; Tue, 1 Dec 2020 11:15:45 +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 0B1BFhNH2016325 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 1 Dec 2020 12:15:43 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 0B1BFgOM2016324; Tue, 1 Dec 2020 12:15:42 +0100 Date: Tue, 1 Dec 2020 12:15:42 +0100 From: Jakub Jelinek To: Richard Biener Cc: Jason Merrill , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] dwarf: Add -gdwarf{32,64} options Message-ID: <20201201111542.GT3788@tucnak> Reply-To: Jakub Jelinek References: <20201201103618.GS3788@tucnak> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, 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-List-Received-Date: Tue, 01 Dec 2020 11:15:50 -0000 On Tue, Dec 01, 2020 at 11:49:43AM +0100, Richard Biener wrote: > On Tue, 1 Dec 2020, Jakub Jelinek wrote: > > > Hi! > > > > The following patch makes the choice between 32-bit and 64-bit DWARF formats > > selectable by command line switch, rather than being hardcoded through > > DWARF_OFFSET_SIZE macro. > > > > The options themselves don't turn on debug info themselves, so one needs > > to use -g -gdwarf64 or similar. > > > > Ok for trunk if it passes bootstrap/regtest? > > OK. Note there's > > /* Various DIE's use offsets relative to the beginning of the > .debug_info section to refer to each other. */ > > typedef long int dw_offset; > > which on L32 hosts means we might not support dwarf64 generation > for CUs that do not fit in 31bits? Should we change that to > int64_t? Or should we sorry() for -gdwarf64 on 32bit hosts? > > There's also > > unsigned long die_abbrev; > > and other uses of '[unsigned] long' in dwarf2out.c. One thing is 32-bit hosts vs. 64-bit targets, and we maybe should indeed use HOST_WIDE_INT for dw_offset; not sure about die_abbrev, if the .debug_abbrev section is over 4GiB in one TU, then that would be already massive amounts of debug info (.debug_info is typically 10-100x times larger than .debug_abbrev). Even the HOST_WIDE_INT dw_offset might not be immediately necessary, if a 32-bit host needs to emit 4GiB of .debug_info for one TU, then I'm pretty sure we need at least 4 times that much of compile memory if not much more, our in memory DIE representation isn't exactly compact. The advantage of DWARF 64-bit is not (at least for the time being) a single TU exceeding the limits, but when linking a shared library with tons of TUs where we exceed those limits then (for some large libraries we are already close to those limits or over them now). Another thing is 32-bit targets. For them the limitations of the object file format (e.g. 32-bit ELF) will not allow > 2GiB debug info anyway, and as I've just tested, e.g. on x86_64 with -m32 -gdwarf64 will not work even on tiny testcases: as: pr64716.o: unsupported relocation type: 0x1 pr64716.s: Assembler messages: pr64716.s:6013: Error: cannot represent relocation type BFD_RELOC_64 as: pr64716.o: unsupported relocation type: 0x1 pr64716.s:6015: Error: cannot represent relocation type BFD_RELOC_64 as: pr64716.o: unsupported relocation type: 0x1 pr64716.s:6017: Error: cannot represent relocation type BFD_RELOC_64 So yes, we can either do a sorry, error, or could just avoid 64-bit relocations (depending on endianity instead of emitting .quad expression_that_needs_relocation emit .long expression_that_needs_relocation, 0 or .long 0, expression_that_needs_relocation So, which way do we want to go? > Do dwarf32 and dwarf64 objects inter-operate just fine (as long as > the linker can resolve all relocations w/o truncating)? I think it should, but whether all debug info consumers and other tools will be able to cope with it remains to be seen. If they have bugs, those should be fixed. By adding the -gdwarf{32,64} switches we allow them to try that. Jakub