From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by sourceware.org (Postfix) with ESMTP id 2C9F2385840D for ; Mon, 5 Feb 2024 12:59:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2C9F2385840D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2C9F2385840D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=78.133.224.34 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707137995; cv=none; b=DK3599Ls5fVxj/Q7jKK/nj76wPzwQmBfmJOFj+JSNd8+TpRQjwiXohXxIKdxdOVXgk+FB29/O8dQMblXcANNdkMYMl3w7UJ8J+lW5WTYXGhwaYdfyeLS05fss671IfNXJtzkPfWzy/sAH1320Ugf1XQl9zcu5CbjlNGsUWF5GY4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707137995; c=relaxed/simple; bh=WyOvUWrnYvneVTx/sKaGchpU0Af/XtbucEvvYq+sNBo=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=TUOuAdEdchhVk4YMnj9LPduu5YcjlVCYwXVjhlSkHqKFYO3LPJQPPfckCZJliYdzRLd53UMnLgwIvu4z9fKxnA0cd9g9mHIDpI+poWFygtM9wyLjiDVj7l3E14xxjhT+Uif1IvZY/47MxEa1EEqs0IRwlyMzSuTWCtvSwln0orY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by angie.orcam.me.uk (Postfix, from userid 500) id EB50592009C; Mon, 5 Feb 2024 13:59:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id E56CB92009B; Mon, 5 Feb 2024 12:59:52 +0000 (GMT) Date: Mon, 5 Feb 2024 12:59:52 +0000 (GMT) From: "Maciej W. Rozycki" To: Nick Clifton cc: YunQiang Su , Xi Ruoyao , binutils@sourceware.org Subject: Re: [PATCH] MIPS: support PCREL GOT access In-Reply-To: <11a02e57-b292-4f1e-b879-a54ca08c2234@redhat.com> Message-ID: References: <20240131083244.718579-1-syq@gcc.gnu.org> <2be4441c3a739fe4c3f7a83097270257c3fcd646.camel@xry111.site> <11a02e57-b292-4f1e-b879-a54ca08c2234@redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1163.3 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 5 Feb 2024, Nick Clifton wrote: > > Any idea how to write ld testcases? > > Normal readelf/objdump can only be sure that it is linked. > > I think that we need to execute the out objects to be sure that it has no > > problems, such as segfault etc. > > You can use the [isnative] test to check to see if the test > is being run natively and then try executing the linked code. This will limit verification however, especially for such a target as the MIPS one, usually found in embedded devices only and therefore typically only verified in a cross-environment. I can't remember when I last run verification with the MIPS target natively if ever. It just takes too long for regular use, and it can obviously only cover whatever the subset of ISA features is that the native system provides. The proper way to handle such verification is to tighten the test cases. Relocations have well-defined semantics, so you can prepare sources such as to get reproducible output you can then match against. That means verifying exact bit patterns in files produced, and you can arrange for boundary cases, such as carry/borrow or overflow, to be verified where applicable too. We have such detailed cases in our testsuite already. Relying on run-time tests to crash if a relocation calculation goes wrong seems rather fragile to me. I can imagine errors to cancel each other for example. Maciej