Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Caroline Tice <cmtice@google.com>
To: Joseph Myers <joseph@codesourcery.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 11:13:24 -0700	[thread overview]
Message-ID: <CABtf2+TZdzcAfxNrkVtZ-4ajGqMRC+PrYZvwcOJ+=hebNTFctQ@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2007161728580.19299@digraph.polyomino.org.uk>

On Thu, Jul 16, 2020 at 10:33 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> 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?

That is a very good point; I suppose this test should be marked to
only work on the architecture for which the test was compiled? (I know
I've seen those kinds of restrictions in testsuites before, although
I'm not sure if the GDB testsuite is currently set up for such
restrictions).

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

The source code for this test case was checked in as part of the patch
recently committed for fixing GDB's handling of DWARF v5 dwo files.
The
source file is in gdb/testsuite/gdb.dwarf2/dw5-rnglist-test.cc

The command used to generate the .object file is added in the comments
of the updated testcase in the patch I attached to the first message
in this thread (in the file
gdb/testsuite/gdb.dwarf2/dw5-rnglist-test.exp.  I did not include the
compiler version information in those comments, but I can certainly
update it to do so.

>
> --
> Joseph S. Myers
> joseph@codesourcery.com


  reply	other threads:[~2020-07-16 18:13 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
2020-07-16 18:13   ` Caroline Tice [this message]
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='CABtf2+TZdzcAfxNrkVtZ-4ajGqMRC+PrYZvwcOJ+=hebNTFctQ@mail.gmail.com' \
    --to=cmtice@google.com \
    --cc=echristo@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=joseph@codesourcery.com \
    --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