[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ARM kernel module supported reloc types
On 30/12/2008, at 11:07 PM, Andrew Doran wrote:
This is slow, a better way to fix the "reach" problem is described
Thanks for the reference. I figured that this sort of solution was
fairly obvious, because, after all, it isn't some mystical third
party that's allocating the VA space, it's the kernel. You know the
thing we are fiddling with right now. Just because I have (had) no
idea where to start doesn't mean it isn't the right answer.
What I find now is that the data is not handled properly (or at
seems to be the case). ...
There is probably a bug in arm's kobj_reloc().
I'm going to try KGDB in an effort to find this. If I can get KGDB to
work, it might make debugging this easier.
One other bug I noticed is that the modules are full of local PC24
relocs. These have already been calculated correctly by the linker,
so there doesn't seem to be a good reason for them to be in the kmod.
I have "if (local) return 0;" at the top of my R_ARM_PC24 case block.
Also, I think Rafal's use of 0xfe as the mask to check for overflow
should be 0xfc. I use pointer arithmetic rather than explicit bit
shifting in my calculations, so I just have 0xff for my overflow
mask. Of course, I can't generate an overflow because the module info
problem causes a trap before any of the global relocs are processed.
Main Index |
Thread Index |