Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Caroline Tice <cmtice@google.com>
Cc: Caroline Tice via Gdb-patches <gdb-patches@sourceware.org>,
	Eric Christopher <echristo@google.com>,
	Tom Tromey <tom@tromey.com>, Simon Marchi <simark@simark.ca>
Subject: Re: [PATCH] Update testsuite mechanism to allow object files as source files.
Date: Thu, 16 Jul 2020 17:33:28 +0000	[thread overview]
Message-ID: <alpine.DEB.2.21.2007161728580.19299@digraph.polyomino.org.uk> (raw)
In-Reply-To: <CABtf2+R75fyqGismHX7HRAVFzZL70PEn8aZjdT53RHS-CaVbUA@mail.gmail.com>

On Thu, 16 Jul 2020, Caroline Tice via Gdb-patches wrote:

> High level summary:
> In some (hopefully rare) cases, certain tests MUST be built with a
> particular compiler to work.  If that compiler is not GCC, then it
> makes it very burdensome for developers to run the GDB testsuite and
> test those tests.  This change allows those tests to use object files
> (generated by the required compiler) as the test source file, so that
> when the test suite is run with GCC those tests will still
> execute/test properly.

How is this expected to work when the GDB being tested is configured for a 
different architecture or OS from that of the checked-in object file and 
may not be able to read its object file format at all?  Will all such 
tests have explicit conditioning on the target for which GDB is 
configured?

On general free software and reproducible builds principles:

* The source for any checked-in object file should be checked in.

* That source should include comments giving all information required to 
be able to reproduce the object file byte-for-byte - for example, the 
exact git commit of the compiler used to generate it, the exact options 
with which that compiler should be configured and the exact command line 
to use with that compiler to generate that object file.  And it should 
have been verified by someone in a different environment from the person 
proposing the addition of such an object file that following those 
instructions does give a byte-for-byte identical object file.

-- 
Joseph S. Myers
joseph@codesourcery.com


  parent reply	other threads:[~2020-07-16 17:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-16 16:50 Caroline Tice
2020-07-16 17:21 ` Andrew Burgess
2020-07-16 18:07   ` Caroline Tice
2020-07-16 18:29     ` Andrew Burgess
2020-07-16 17:33 ` Joseph Myers [this message]
2020-07-16 18:13   ` Caroline Tice
2020-07-16 18:47     ` Andrew Burgess
2020-07-16 20:35     ` Joseph Myers
2020-07-16 20:12   ` Tom Tromey
2020-07-16 21:10     ` Caroline Tice
2020-07-16 21:16       ` Eric Christopher
2020-07-17  9:48         ` Andrew Burgess
2020-07-17 16:05           ` Caroline Tice
2020-07-17  9:43       ` Andrew Burgess
2020-07-17 17:45         ` Tom Tromey

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.2007161728580.19299@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=cmtice@google.com \
    --cc=echristo@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    --cc=tom@tromey.com \
    /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