linux-mips
[Top] [All Lists]

Re: [PATCH] mm/pg-r4k.c: Dump the generated code

To: Thiemo Seufer <ths@networkno.de>
Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Wed, 3 Oct 2007 14:51:10 +0100 (BST)
Cc: Franck Bui-Huu <vagabon.xyz@gmail.com>, Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
In-reply-to: <20071003131158.GL16772@networkno.de>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <Pine.LNX.4.64N.0710021447470.32726@blysk.ds.pg.gda.pl> <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de>
Sender: linux-mips-bounce@linux-mips.org
On Wed, 3 Oct 2007, Thiemo Seufer wrote:

> Then you have the worst of both approaches: The nicely readable
> disassembly will change under you feet, and you still need relocation
> annotations etc. for CPU-specific fixups. The end-result is likely
> more complicated and opaque than what we have now.

 Well, to be honest what we have now is very good.  One trouble at the 
beginning, just after we switched from the old approach, was limited 
ability to get at what really is generated and therefore tough time to 
determine what was going on if something was wrong.  With these debug 
dumps in place it is gone now too.

 There is one limitation though -- unlike with ready-writted assembly to 
debug this code you typically need to have a specific system that shows a 
problem.  If you do not have one chances are you can miss a condition 
somewhere and therefore the problem.  Once you have the right piece of 
hardware, debugging is easy -- it took me half of a day if not less to 
sort out all the issues with the R3000 TLB handlers that we had once I got 
my hands on a suitable system.

 And as with everything, there is still room for improvement though.  For 
example I have noticed for the 64-bit TLB refill handler the path for 
vmalloc()ed pages may fit entirely in half of the space available.  Which 
means whatever is emitted after "eret" may be shifted to the TLB refill 
space at 0x80000000 saving the branch from the XTLB space at its end.  
That is probably doable with reasonably little effort given that we have 
support for "relocations".

  Maciej

<Prev in Thread] Current Thread [Next in Thread>