devicetree-compiler.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

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