linux-mips
[Top] [All Lists]

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

To: "Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: Ralf Baechle <ralf@linux-mips.org>
Date: Wed, 3 Oct 2007 02:00:53 +0100
Cc: Thiemo Seufer <ths@networkno.de>, linux-mips@linux-mips.org
In-reply-to: <Pine.LNX.4.64N.0710021651490.32726@blysk.ds.pg.gda.pl>
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> <Pine.LNX.4.64N.0710021651490.32726@blysk.ds.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.14 (2007-02-12)
On Tue, Oct 02, 2007 at 05:08:05PM +0100, Maciej W. Rozycki wrote:

> > I have a patch which makes the generated code accessible through a
> > procfs file.  That can easily be converted back into a .o file and then
> > be disassembled.  So it's now a question of which variant is preferable.
> 
>  There is no need to go through such hassle even:
> 
> $ objdump -b binary -m mips:4000 -d /proc/foo
> 
> or suchlike should work (the program seems to be sensitive to the file 
> size though, so it better be non-zero).
> 
> > I don't mind - it's just that I've never been a friend of leaving much
> > debugging code or features around.  99% of the time it is just make the
> > code harder to read and maintain.
> 
>  In this case I would let these bits stay in though.  The bootstrap log 
> always works and can be captured with the serial console or read from the 
> screen, and if there is a subtle breakage in these generated bits then the 
> system may never get far enough for procfs to be accessible.  It is these 
> moments it matters the most.

I originally wrote my variant as a tool for optimization.

Anyway, queued for 2.6.24.  That is if 2.6.23 is ever released ;-)

  Ralf

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