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
next prev 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