From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Devicetree Compiler
<devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Julia Lawall <Julia.Lawall-L2FTfq7BK8M@public.gmane.org>,
Frank Rowand
<frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [RFC PATCH] checks: Use source position information for check failures
Date: Thu, 11 Jan 2018 10:43:40 +1100 [thread overview]
Message-ID: <20180110234340.GD24770@umbus.fritz.box> (raw)
In-Reply-To: <CAL_Jsq+Brr4e1ZvPapnpRLb5hJPsyBjxoZAdDeaqsD2y0Ma6Jw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 6155 bytes --]
On Wed, Jan 10, 2018 at 10:41:54AM -0600, Rob Herring wrote:
> On Tue, Jan 9, 2018 at 11:30 PM, David Gibson
> <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
> > On Mon, Jan 08, 2018 at 04:49:27PM -0600, Rob Herring wrote:
> >> Now that we retain source position information of nodes and properties,
> >> make that the preferred file name (and position) to print out in check
> >> failures. This will greatly simplify finding and fixing check errors
> >> because most errors are in included source .dtsi files and they get
> >> duplicated every time the source file is included.
> >>
> >> For now, only converting a few locations and using a new macro name. I
> >> will convert all FAIL occurences once we agree on the new syntax. Also,
> >> after this, some checks may need some rework to have more specific
> >> line numbers of properties rather than nodes.
> >>
> >> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >
> > So, I like the basic idea here - something I've kind of wanted for a while.
> >
> >> ---
> >> This is based on Julia's annotation series.
> >
> > But that series will need a new spin, which will require a new spin of
> > this at the last.
>
> Yes, I expected that.
>
> >> checks.c | 28 ++++++++++++++++++++++------
> >> 1 file changed, 22 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/checks.c b/checks.c
> >> index 7845472742e0..2078c0fe75eb 100644
> >> --- a/checks.c
> >> +++ b/checks.c
> >> @@ -19,6 +19,7 @@
> >> */
> >>
> >> #include "dtc.h"
> >> +#include "srcpos.h"
> >>
> >> #ifdef TRACE_CHECKS
> >> #define TRACE(c, ...) \
> >> @@ -72,7 +73,8 @@ struct check {
> >> #define CHECK(nm_, fn_, d_, ...) \
> >> CHECK_ENTRY(nm_, fn_, d_, false, false, __VA_ARGS__)
> >>
> >> -static inline void PRINTF(3, 4) check_msg(struct check *c, struct dt_info *dti,
> >> +static inline void PRINTF(4, 5) check_msg(struct check *c, struct dt_info *dti,
> >> + struct srcpos *pos,
> >> const char *fmt, ...)
> >> {
> >> va_list ap;
> >> @@ -80,8 +82,15 @@ static inline void PRINTF(3, 4) check_msg(struct check *c, struct dt_info *dti,
> >>
> >> if ((c->warn && (quiet < 1))
> >> || (c->error && (quiet < 2))) {
> >> + const char *file_str;
> >> + if (pos)
> >> + file_str = srcpos_string(pos);
> >> + else if (streq(dti->outname, "-"))
> >> + file_str = "<stdout>";
> >> + else
> >> + file_str = dti->outname;
> >> fprintf(stderr, "%s: %s (%s): ",
> >> - strcmp(dti->outname, "-") ? dti->outname : "<stdout>",
> >> + file_str,
> >> (c->error) ? "ERROR" : "Warning", c->name);
> >
> > Incidentally, the reason it currently shows the output name, which
> > seems weird at first glance, is so that if you have a whole batch of
> > dtc commands running from a script or Makefile, you can at least tell
> > which command caused the check failure.
>
> Yes, better than nothing...
>
> >
> >> vfprintf(stderr, fmt, ap);
> >> fprintf(stderr, "\n");
> >> @@ -93,7 +102,14 @@ static inline void PRINTF(3, 4) check_msg(struct check *c, struct dt_info *dti,
> >> do { \
> >> TRACE((c), "\t\tFAILED at %s:%d", __FILE__, __LINE__); \
> >> (c)->status = FAILED; \
> >> - check_msg((c), dti, __VA_ARGS__); \
> >> + check_msg((c), dti, NULL, __VA_ARGS__); \
> >> + } while (0)
> >> +
> >> +#define FAIL_POS(c, dti, p, ...) \
> >> + do { \
> >> + TRACE((c), "\t\tFAILED at %s:%d", __FILE__, __LINE__); \
> >> + (c)->status = FAILED; \
> >> + check_msg((c), dti, p, __VA_ARGS__); \
> >> } while (0)
> >>
> >> static void check_nodes_props(struct check *c, struct dt_info *dti, struct node *node)
> >> @@ -126,7 +142,7 @@ static bool run_check(struct check *c, struct dt_info *dti)
> >> error = error || run_check(prq, dti);
> >> if (prq->status != PASSED) {
> >> c->status = PREREQ;
> >> - check_msg(c, dti, "Failed prerequisite '%s'",
> >> + check_msg(c, dti, NULL, "Failed prerequisite '%s'",
> >> c->prereq[i]->name);
> >> }
> >> }
> >> @@ -1049,7 +1065,7 @@ static void check_avoid_unnecessary_addr_size(struct check *c, struct dt_info *d
> >> }
> >>
> >> if (!has_reg)
> >> - FAIL(c, dti, "unnecessary #address-cells/#size-cells without \"ranges\" or child \"reg\" property in %s",
> >> + FAIL_POS(c, dti, node->srcpos, "unnecessary #address-cells/#size-cells without \"ranges\" or child \"reg\" property in %s",
> >> node->fullpath);
> >
> > Checks are already associated with a node, would it make more sense to
> > print the position information from the general code?
>
> Not sure I follow the question. You mean pass in the struct node and
> get the srcpos and fullpath inside check_msg?
Basically, yes.
> While checks are associated with nodes, specific error messages may be
> associated with properties. This is one example where we could make
> the error message be the exact line (of the #address-cells or
> #size-cells), but that would require re-working the check a bit to get
> the property structs (and srcpos).
Ah, good point.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-01-10 23:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-08 22:49 [RFC PATCH] checks: Use source position information for check failures Rob Herring
[not found] ` <20180108224927.1016-1-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2018-01-10 5:30 ` David Gibson
[not found] ` <20180110053020.GD19773-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
2018-01-10 16:41 ` Rob Herring
[not found] ` <CAL_Jsq+Brr4e1ZvPapnpRLb5hJPsyBjxoZAdDeaqsD2y0Ma6Jw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-10 23:43 ` David Gibson [this message]
[not found] ` <20180110234340.GD24770-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
2018-01-11 16:19 ` Rob Herring
[not found] ` <CAL_JsqJeh5GFsqjfVuQ-StiPGNzej6Su9k+DS+joPYRPqTB1Ww-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-15 2:53 ` David Gibson
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=20180110234340.GD24770@umbus.fritz.box \
--to=david-xt8fgy+axnrb3ne2bgzf6laj5h9x9tb+@public.gmane.org \
--cc=Julia.Lawall-L2FTfq7BK8M@public.gmane.org \
--cc=devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 NNTP newsgroup(s).