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 4ED05385481D for ; Fri, 26 Feb 2021 10:35:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4ED05385481D 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-37-Q1BNYPOtM9GMF5sbGFvvig-1; Fri, 26 Feb 2021 05:35:52 -0500 X-MC-Unique: Q1BNYPOtM9GMF5sbGFvvig-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C88E218BA29C; Fri, 26 Feb 2021 10:35:50 +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 6AF5F5D9D2; Fri, 26 Feb 2021 10:35:50 +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 11QAZlWq3613529 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 26 Feb 2021 11:35:47 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 11QAZj7e3613526; Fri, 26 Feb 2021 11:35:45 +0100 Date: Fri, 26 Feb 2021 11:35:45 +0100 From: Jakub Jelinek To: Mark Wielaard Cc: Tom de Vries , dwz@sourceware.org Subject: Re: [PATCH][testsuite] Fix pr25109.sh on riscv64 Message-ID: <20210226103545.GW4020736@tucnak> Reply-To: Jakub Jelinek References: <20210226101421.GA29849@delia> <20210226102831.GD3014@wildebeest.org> MIME-Version: 1.0 In-Reply-To: <20210226102831.GD3014@wildebeest.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, 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: dwz@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dwz mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2021 10:35:57 -0000 On Fri, Feb 26, 2021 at 11:28:31AM +0100, Mark Wielaard wrote: > On Fri, Feb 26, 2021 at 11:14:23AM +0100, Tom de Vries wrote: > > On riscv64, I run into: > > ... > > cc main.c no-multifile-prop-dw.S -o no-multifile-prop > > no-multifile-prop-dw.S: Assembler messages: > > no-multifile-prop-dw.S:25: Error: non-constant .uleb128 is not supported > > make: *** [Makefile:99: no-multifile-prop] Error 1 > > ... > > > > Fix this by allowing to fail to build the test-case, and marking it as > > unsupported. > > > > Any comments? > > If it doesn't even build then there is not much else we can do than > skip it. So I would push this. > > But this is a little surprising. > The construct seems like it is represented by a known constant at compile time: > > .uleb128 .Lexpr_end4 - .Lexpr_start3/* expression */ > .Lexpr_start3: > .byte 0xf2 /* DW_OP_GNU_implicit_pointer */ > .4byte .Llabel2 > .sleb128 0 > .Lexpr_end4: > > There isn't anything between the two labels that can have a variable > size. So it might be a good idea to file a bug report against > binutils as for not allowing this on riscv64. I believe the riscv people explain it by aggressive linker optimizations that make those not to work, but perhaps that applies to normal sections, but don't see how can that apply to .debug* sections... They shouldn't be doing any kind of aggressive linker relaxations on .debug*. Jakub