All of lore.kernel.org
 help / color / mirror / Atom feed
From: Franck Bui-Huu <vagabon.xyz@gmail.com>
To: Thiemo Seufer <ths@networkno.de>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 3/4] tlbex.c: cleanup debug code
Date: Sun, 14 Oct 2007 22:20:20 +0200	[thread overview]
Message-ID: <47127A04.20008@gmail.com> (raw)
In-Reply-To: <20071012171120.GI3379@networkno.de>

Thiemo Seufer wrote:
> I don't like this patch. I wrote the code to
> a) print the handler before the (potentially fatal) memcpy. Touching
>    EBASE for the first time is a place where things like to go wrong.

Sorry I don't see what you mean...

Do you mean ebase (BTW this name sounds very local...) can be set to
an incorrect value and therefore the memcpy can get mad ?

If so I would say that with this patch applied you can easily guess
that an issue happen in this place because the log would be:

	Synthesized TLB refill handler (x instructions)
	<nothing>

and there would be no dump of the handler.

Whereas currently we would have:

	Synthesized TLB refill handler (x instructions)
	<handler dump>
	<nothing>

and now you don't know if the crash happen in the memcpy or later...

And it seems better to dump the code which is going to be _executed_
instead of a temporary buffer.

> b) avoid printing leading nops which are never executed. The trailing
>    nops have less potential for confusion.

Well, I disagree for 2 reasons:

   1/ By printing the leading nops you can detect a bug which would
      wrongly write in this unused part of the handler. That's one of
      the reason I added the handler instruction addresses BTW: to
      skip easily this part when reading the dump.

   2/ This is just debug code and it should not make the real code
      harder to read. Take a look at the end of
      build_r4000_tlb_refill_handler() function. It's not really
      obvious that this part is only for debug except the memcpy.

But you're the maintainer of this file so if you still think I should
drop this patch then I will.

Thanks.
		Franck

  reply	other threads:[~2007-10-14 20:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-12  6:39 [PATCH 0/4] Cleanup tlbex.c Franck Bui-Huu
2007-10-12  6:41 ` [PATCH 1/4] tlbex.c: Cleanup __init usages Franck Bui-Huu
2007-10-12  9:07   ` Atsushi Nemoto
2007-10-12 16:01     ` Johannes Dickgreber
2007-10-14 19:24     ` Franck Bui-Huu
2007-10-12  6:42 ` [PATCH 2/4] tlbex.c: cleanup include files Franck Bui-Huu
2007-10-12  6:43 ` [PATCH 3/4] tlbex.c: cleanup debug code Franck Bui-Huu
2007-10-12 17:11   ` Thiemo Seufer
2007-10-14 20:20     ` Franck Bui-Huu [this message]
2007-10-12  6:43 ` [PATCH 4/4] tlbex.c: use __cacheline_aligned instead of __tlb_handler_align attribute Franck Bui-Huu

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=47127A04.20008@gmail.com \
    --to=vagabon.xyz@gmail.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=ths@networkno.de \
    /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.