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
next prev parent 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