"Magnus Damm" <[EMAIL PROTECTED]> writes: > Hi Eric, > > On 7/6/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote: >> "Magnus Damm" <[EMAIL PROTECTED]> writes: >> > On 7/6/06, Vivek Goyal <[EMAIL PROTECTED]> wrote: >> >> On Fri, Jun 30, 2006 at 05:45:58PM +0900, Magnus Damm wrote: >> >> > Here comes a working snapshot of some relocation code that I've been >> >> > hacking on lately. I've only tested the code in qemu-system-i386, but >> >> > x86_64 and other architectures may work too. >> > >> > [snip] >> > >> >> Looks like we are relocating everything including absolute symbols. As >> >> long >> >> as absolute symbols are representing address, its fine (like __bss_start) >> >> but if they happen to represent a value which is not supposed to change >> >> due to loading of vmlinux at a different address, it will be an issue. >> > >> > Yes, all symbols should be relocated by my patch. That may of course >> > be wrong, but in my mind symbols were only used to represent code or >> > data that is present at a certain address. So when the base address is >> > changed all symbols should be adjusted as well. >> > >> > I understand that it is possible to create a symbol that points to a >> > fixed address say mapping some hardware resource, but is that a >> > strategy currently used by Linux? >> >> Nope absolute symbols should not be changed in particular you will >> mess up the linux-gate.so and the like. > > I did some more research and it looks like I'm wrong. So absolute > symbols should be handled in a different way - I'll modify patches to > get that working. > > The absolute symbols we are talking about are the ones that could be > extracted from vmlinux with the following line, right? > > readelf -s vmlinux | grep ABS | grep -v FILE > >> >> Eric had posted a patch in the past which made some the absolute symbols >> >> section relative. >> >> >> >> http://marc.theaimsgroup.com/?l=linux-kernel&m=112266670613361&w=2 >> > >> > Nice. >> > >> > I actually came across that patch a while ago, but I'm not sure how >> > much it will help with my current "relocate all symbols" strategy. If >> > we treat absolute symbols differently from relative then I'm sure the >> > patch will help. >> >> It's needed. > > Yes. =) > >> > I've attached a newer version of the kernel patch. The kallsyms >> > utility is probably unchanged, but a CONFIG_RELOCATABLE variable has >> > been introduced together with some modpost changes. >> > >> > The patch builds both on i386 and x86_64. I am however unable to >> > relocate the kernel using my patched kexec tool on x86_64 right now. >> >> I think this is a really bad idea for x86_64, because it strongly >> limits us to where we can relocate the kernel at run time. >> (More later) > > While at it, please explain what you think is a bad idea. The idea > that kexec-tools does the relocation or that my patch is badly > implemented? Or both? =)
Neither (although I think kexec-tools actually processing the relocations is silly) I think processing relocations for handling x86_64 is a bad idea for x86_64 because it means you can only put your kernel in the first 2G of RAM. For simply handling kexec on panic it is probably ok, and just short sighted. For more interesting uses like Xen or running on machines that say reserve the first 4G for memory mapped I/O I think it is just unfortunate. Eric _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
