From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Nick Clifton <nickc@redhat.com>
Cc: YunQiang Su <syq@gcc.gnu.org>, Xi Ruoyao <xry111@xry111.site>,
binutils@sourceware.org
Subject: Re: [PATCH] MIPS: support PCREL GOT access
Date: Mon, 5 Feb 2024 12:59:52 +0000 (GMT) [thread overview]
Message-ID: <alpine.DEB.2.21.2402051243280.2376@angie.orcam.me.uk> (raw)
In-Reply-To: <11a02e57-b292-4f1e-b879-a54ca08c2234@redhat.com>
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
next prev parent reply other threads:[~2024-02-05 12:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-31 8:32 YunQiang Su
2024-01-31 9:24 ` Xi Ruoyao
2024-02-02 1:25 ` YunQiang Su
2024-02-05 11:48 ` Nick Clifton
2024-02-05 12:59 ` Maciej W. Rozycki [this message]
2024-02-06 16:52 ` YunQiang Su
2024-02-06 19:47 ` Maciej W. Rozycki
2024-02-25 16:00 ` YunQiang Su
2024-03-01 17:38 ` Maciej W. Rozycki
2024-03-15 13:44 ` YunQiang Su
2024-02-02 6:39 [PATCH] MIPS: Support " YunQiang Su
2024-02-02 6:42 ` YunQiang Su
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.2402051243280.2376@angie.orcam.me.uk \
--to=macro@orcam.me.uk \
--cc=binutils@sourceware.org \
--cc=nickc@redhat.com \
--cc=syq@gcc.gnu.org \
--cc=xry111@xry111.site \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).