public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@imgtec.com>
To: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
Cc: Alan Modra <amodra@gmail.com>, Nick Clifton <nickc@redhat.com>,
	<binutils@sourceware.org>
Subject: Re: [PATCH] PR ld/21233: Avoid sweeping forced-undefined symbols in section GC
Date: Wed, 05 Apr 2017 16:03:00 -0000	[thread overview]
Message-ID: <alpine.DEB.2.00.1704050237320.25796@tp.orcam.me.uk> (raw)
In-Reply-To: <201704050113.v351DhHw028416@ignucius.se.axis.com>

On Wed, 5 Apr 2017, Hans-Peter Nilsson wrote:

> > 2. File a PR referring to commit d968975277ba and its discussion and KFAIL 
> >    the affected test cases for the problematic targets.
> 
> (or rather xfail; I don't know if there's a way to kfail with
> run_ld_link_tests and I don't think we use that in binutils.)

 Of course there is, see commit 3807734dbe48 for a somewhat non-trivial 
example.

 AFAIK XFAIL is unsuitable as it marks a problem with the test environment 
rather than a bug in the component being tested.  KFAIL OTOH forces you to 
create a PR, which prompts you to have the issue recorded in the bug 
tracker (also giving a chance for someone else to pick it up) rather than 
papered over and then forgotten.

 KFAIL's usage is indeed much more prominent in GDB than in binutils.

> I'm not a general maintainer, but FWIW my preference would have
> been this, to xfail the failing parts and also add affected
> maintainers on the ticket.

 On second thoughts there can be multiple bugs here, quite likely one or 
more per BFD backend.  So it doesn't really scale well.  And any active 
maintainer will notice the regression in their routine runs; XFAIL/KFAIL 
may OTOH be missed (my test scripts certainly do not pay attention to 
these on the basis of them being expected/known; I'd have to go through 
full logs to catch them).

> To those interested: the run_ld_link_tests source shows how to
> add xfails for a target or use this as an example.  (Not my
> preferred test-driver function, I prefer to iterate on
> run_dump_test *.d files; with a driver in place sometimes I only
> have to add that one file with a descriptive comment inside.)

 I prefer `run_dump_test' too where feasible, but it is not suitable for 
some test cases, not at least without bending backwards.

> As a sanity check, I made sure mips-linux still passed all
> tests.

 Thanks.

> diff --git a/ld/testsuite/ld-elf/shared.exp b/ld/testsuite/ld-elf/shared.exp
> index be30ec0..291f9e1 100644
> --- a/ld/testsuite/ld-elf/shared.exp
> +++ b/ld/testsuite/ld-elf/shared.exp
> @@ -152,7 +153,7 @@ if { [check_gc_sections_available] } {
>  	    "tmpdir/libpr21233.so" "" \
>  	    {pr21233.s} \
>  	    {{readelf --dyn-syms pr21233.sd}} \
> -	    "pr21233-3"]]
> +	     "pr21233-3"]] "cris*-*-*"

 Indentation issue here.

  Maciej

  reply	other threads:[~2017-04-05 16:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-27 11:39 Maciej W. Rozycki
2017-04-04  8:47 ` Alan Modra
2017-04-04 22:43   ` Maciej W. Rozycki
2017-04-05  2:11     ` Alan Modra
2017-04-05 16:07       ` Maciej W. Rozycki
2017-04-19 12:02     ` Christophe Lyon
2017-04-19 12:52       ` Maciej W. Rozycki
2017-04-19 13:55         ` Christophe Lyon
2017-04-05  1:13 ` Hans-Peter Nilsson
2017-04-05 16:03   ` Maciej W. Rozycki [this message]
2017-04-05 21:38     ` Hans-Peter Nilsson

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.00.1704050237320.25796@tp.orcam.me.uk \
    --to=macro@imgtec.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=hans-peter.nilsson@axis.com \
    --cc=nickc@redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).