linux-mips
[Top] [All Lists]

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

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Tue, 2 Oct 2007 17:08:05 +0100 (BST)
Cc: Thiemo Seufer <ths@networkno.de>, linux-mips@linux-mips.org
In-reply-to: <20071002154918.GA11312@linux-mips.org>
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>
Sender: linux-mips-bounce@linux-mips.org
On Tue, 2 Oct 2007, Ralf Baechle 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.

  Maciej

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