[Top] [All Lists]

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

To: Franck Bui-Huu <>
Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: Thiemo Seufer <>
Date: Wed, 3 Oct 2007 14:11:58 +0100
Cc: Ralf Baechle <>, "Maciej W. Rozycki" <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <>
User-agent: Mutt/1.5.16 (2007-06-11)
Franck Bui-Huu wrote:
> Ralf Baechle wrote:
> > 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.
> > 
> Yeah this kind of code is really hard to follow and therefore hard to
> maintain I guess.
> I'm wondering if we couldn't try to implement such code generator by
> using a tools/scripts during the build process.
> This tool could emit
> the assembler code during the early phase of the build into an
> assembler file and then it could compiled like any other one. I see a
> 3 main benefits:
>   - It would simplify a lot the kernel code.
>   - Decrease the size of the kernel
>   - Easy to read the generated disassembly
> One issue to deal with is that some instructions need to be emitted
> according to the type of the cpu which can only be determined at run
> time. In this case we could leave some rooms into the generated code
> for additional instructions which could be filled/patched during the
> boot time by using a 'patch table'. If the cpu doesn't need to patch
> the generated code then the useless space would be discarded when
> installing the handler in its final place.

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.


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