public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
To: libc-alpha@sourceware.org
Subject: Fwd: [PATCH] Add valgrind smoke test
Date: Fri, 2 Jul 2021 15:18:30 +0200	[thread overview]
Message-ID: <CAJVr-EO=c6O=uawedOUWNqtrTiC4ABg3AeaUcrRTp3MWMU_kxA@mail.gmail.com> (raw)
In-Reply-To: <CAJVr-EMvXXXx63a0Ht9iAxo-iV9fMpuo16c7ySqOukN10tpAVA@mail.gmail.com>

---------- Forwarded message ---------
From: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Date: Fri, Jul 2, 2021 at 3:17 PM
Subject: Re: [PATCH] Add valgrind smoke test
To: Joseph Myers <joseph@codesourcery.com>




On Mon, May 24, 2021 at 9:29 PM Joseph Myers <joseph@codesourcery.com>
wrote:

> On Mon, 24 May 2021, Carlos O'Donell via Libc-alpha wrote:
>
> > > +# Run smoke tests with valgrind to verify dynamic loader
> > > +ifneq ($(VALGRIND),false)
> > > +tests-special += $(objpfx)valgrind-smoke-test.out
> > > +$(objpfx)valgrind-smoke-test.out: $(objpfx)ld.so
> > > +   $(common-objpfx)testrun.sh --tool=valgrind-test /usr/bin/true > $@
> > > +   $(common-objpfx)testrun.sh --tool=valgrind-test /usr/bin/true
> --help >> $@
> > > +endif
> > Does this work for cross-compiling?
> >
> > Do you correctly detect the target valgrind and does the test wrapper
> > allow the correct execution of valgrind on the target system?
>
> My expectation is that <host>-valgrind won't exist - but AC_CHECK_TOOL is
> documented as falling back to the tool without a host prefix if a prefixed
> version doesn't exist, which is a problem.  Logically, this test should
> run if valgrind is available on the test system (which would need to be
> determined when the tests are run, test-wrapper isn't available when glibc
> is built), but the test-wrapper interface doesn't strictly support running
> arbitrary installed programs like that.  So you might need a test program
> (run on the test system via test-wrapper) that itself checks for valgrind
> being available in the PATH and runs it or returns UNSUPPORTED if not
> available.  That is, something like nptl/tst-pthread-gdb-attach.c, which
> handles checking for whether gdb is available.
>

 So I should not be using
+AC_CHECK_TOOL([VALGRIND], [valgrind], [false])
at all in my case?
I consider this patch rejected then and will try to come with something like
nptl/tst-pthread-gdb-attach.c - for example elf/tst-valgrind-smoke.c.

Thank you for the review,
Alexandra

  parent reply	other threads:[~2021-07-02 13:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-24 12:15 Alexandra Hájková
2021-05-24 14:28 ` Carlos O'Donell
2021-05-24 19:28   ` Joseph Myers
2021-06-28  8:29     ` Florian Weimer
2021-06-28 18:33       ` Joseph Myers
     [not found]     ` <CAJVr-EMvXXXx63a0Ht9iAxo-iV9fMpuo16c7ySqOukN10tpAVA@mail.gmail.com>
2021-07-02 13:18       ` Alexandra Petlanova Hajkova [this message]
2021-07-05 20:28         ` Fwd: " Joseph Myers

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='CAJVr-EO=c6O=uawedOUWNqtrTiC4ABg3AeaUcrRTp3MWMU_kxA@mail.gmail.com' \
    --to=ahajkova@redhat.com \
    --cc=libc-alpha@sourceware.org \
    /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).