Note that I know nothing about gcc internals. Anyway, here goes.
The variable stuff is solved by having a pointer to a pointer.
In the code there are pointers to a new pointer which points to the data.
Of course this means changing gcc and so on and loads of other stuff.
And some performance loss of course.
What you do to make a more complex patch is to insert a jump to the new code
and if necessary back again. This means that you must have predefined space for
patches or the possibility to increase size while running.
BR Magnus Back
>Christer Weinigel writes:
>
>->You can't change the addresses of variables or functions if the only
>->information you have available is the System.map file. The addresses
>->of variables and functions in the kernel are resolved at link time and
>->are encoded in the instructions themselves.
>
>"address of var encoded into instruction themselves".
>
>I realized that a while after I wrote my post :(
>
>->I might add that I believe that what you're trying to do is extremely
>->hard to get right. Changing an off-by-one error which just means
>->replacing a JLT with a JLE instruction (were both instructions are the
>->same size and have the same operands) is almost simple. Doing more
>->complex changes makes my brain ache, just thinking about it. :-)
>
>In case of ip_glue() my luck was that all function/variables which ip_glue
>used were either exported symbols or were pointers. So it was straight-
>forward to write ip_glue_new() and change first few instructions of
>ip_glue() to JMP to the ip_glue_new().
>
>
>Since it seems that it is dead-end, I think I'll just polish code a bit
>and post it on web ... mabye some one comes up with better idea.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html