public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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

  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).