All of lore.kernel.org
 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 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.