Linux MIPS Architecture development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox