public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: YunQiang Su <syq@gcc.gnu.org>
Cc: Nick Clifton <nickc@redhat.com>, Xi Ruoyao <xry111@xry111.site>,
	 binutils@sourceware.org
Subject: Re: [PATCH] MIPS: support PCREL GOT access
Date: Tue, 6 Feb 2024 19:47:33 +0000 (GMT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2402061933380.2376@angie.orcam.me.uk> (raw)
In-Reply-To: <CAKcpw6UJH-4PFHqnwWL5TpNK0D6g_zjCUm7BTsPiDd0gBOYxiA@mail.gmail.com>

On Wed, 7 Feb 2024, YunQiang Su wrote:

> >  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.
> >
> 
> In fact I am worried that we use the wrong GOT slot, and the ldso
> set the GOT incorrectly for use., which is not easy to test statically.
> Bit by bit comparison is not easy, due to that the final executables
> contains something from libc, which may have quite different versions.

 You don't have to use libc at link time and using components from outside 
binutils is what makes compiled tests so problematic in our testsuite.  We 
avoid using external components where feasible.

 We can try and do our best to produce correctly linked executables and 
shared libraries and provide testsuite coverage for what we do, and then 
if you want to verify ld.so, then do it with the testsuite for the 
relevant project: glibc, uClibc, musl, whatever.

  Maciej

  reply	other threads:[~2024-02-06 19:47 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
2024-02-06 16:52         ` YunQiang Su
2024-02-06 19:47           ` Maciej W. Rozycki [this message]
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.2402061933380.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).