On 30/12/2008, at 11:07 PM, Andrew Doran wrote:
This is slow, a better way to fix the "reach" problem is described here:http://mail-index.netbsd.org/port-arm/2008/12/19/msg000587.html
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 least thatseems 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.
Cheers, Lloyd