From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] [RFC] zram01: Fix on ppc64le
Date: Thu, 9 Feb 2017 15:56:48 +0100 [thread overview]
Message-ID: <20170209145648.GF12673@rei.lan> (raw)
In-Reply-To: <116936368.2235095.1486651688068.JavaMail.zimbra@redhat.com>
Hi!
> > It's especially there for code that defines TST_NO_DEFAULT_MAIN but one
> > can argue that this is special case and if you define that macro you
> > should know what you are doing anyway...
> >
> > But still I prefer to throw error message instead of segfaulting while
> > trying to deference NULL pointer.
>
> I was suggesting we skip update_results(), not to let it segfault.
Sorry I was blind. That makes much more sense. Let's go with that one,
instead of the:
"[LTP] [PATCH 1/6] tst_test: Allow priting TINFO without initialized IPC"
> > > > Maybe
> > > > we could patch things up so that we could use SAFE_MACROS() in cleanup
> > > > as well...
> > >
> > > This should be doable with some flag we set in do_test_cleanup(), to skip
> > > further calls.
> >
> > I'm nearly finished with RFC patch. The main problem is the
> > __attribute__((noreturn)) that has been added for various tst_brk*
> > variants. So in the end it looks like only solution is to do the
> > tst_brk_() redirection in the safe_macros.c, since we cannot return from
> > tst_brkm_() since the return address is not stored on stack because it
> > has noreturn attribute. And dropping the noreturn attribute from
> > tst_brkm_() is not an option either, since that generates a ton of
> > "control reaches end of non-void function" warnings.
>
> Vast majority is from single header file:
>
> $ grep "reaches end of non-void" log.txt | sort | uniq | wc -l
> 328
>
> $ grep "reaches end of non-void" log.txt | sort | uniq | grep compat_16.h | wc -l
> 289
That is still 39 occurences to fix all over the place plus the
compat_16.h header. Have a look at the patch I've just send, I think
that it's a bit easier than patching all the tests to avoids warnings...
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2017-02-09 14:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-31 13:44 [LTP] [PATCH] [RFC] zram01: Fix on ppc64le Cyril Hrubis
2017-01-31 16:14 ` Jan Stancek
2017-02-01 9:45 ` Cyril Hrubis
2017-02-01 10:59 ` Jan Stancek
2017-02-02 15:22 ` Cyril Hrubis
2017-02-08 11:10 ` Cyril Hrubis
2017-02-09 12:02 ` Cyril Hrubis
2017-02-09 13:24 ` Jan Stancek
2017-02-09 14:00 ` Cyril Hrubis
2017-02-09 14:48 ` Jan Stancek
2017-02-09 14:56 ` Cyril Hrubis [this message]
2017-08-15 9:23 ` Cyril Hrubis
2017-08-15 11:44 ` Jan Stancek
2017-08-15 12:38 ` Cyril Hrubis
2017-08-15 12:48 ` Jan Stancek
2017-08-15 12:57 ` Cyril Hrubis
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=20170209145648.GF12673@rei.lan \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.