"Magnus Damm" <[EMAIL PROTECTED]> writes: > Hi Vivek, > > Thanks for your review! > > 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. >> Probably we can skip relocating absolute symbols but then we shall have to >> make sure none of the absolute symbols is representing a information which >> is variable like section start addresss. > > Or maybe it would make sense to only adjust relocations that are using > symbols which are part of certain types of sections. > >> 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. > >> [..] >> > --- 0003/Makefile >> > +++ work/Makefile 2006-06-30 12:57:25.000000000 +0900 >> > @@ -573,7 +573,7 @@ vmlinux-lds := arch/$(ARCH)/kernel/vmli >> > # May be overridden by arch/$(ARCH)/Makefile >> > quiet_cmd_vmlinux__ ?= LD $@ >> > cmd_vmlinux__ ?= $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \ >> > - -T $(vmlinux-lds) $(vmlinux-init) \ >> > + --emit-reloc -T $(vmlinux-lds) $(vmlinux-init) \ >> >> >> Should this be --emit-reloc or --emit-relocs > > Oh, it should be --emit-relocs. Sorry about that. > >> Ok. So here we are trying to relocate an executable by retaining reloc >> information. >> >> FYI, In the past Eric had posted a working prototype where >> he was compiling the kernel as a shared library (-shared) which was >> compiled for physical address 1MB and relocating it if was loaded >> at different address. He was doing relocation at kernel run time. > > I've seen a similar approach (maybe it is the same code, I don't know) > used by a former colleague of mine (Jan Kratochvil, CC:ed). If you are > interested then you can have look at the details in > minik-patch-2.6.12-2.1 present in the mkdump-2.1 release. Have a look > at http://mkdump.sourceforge.net/ for more information. > >> Not sure which approach is better but got a question. By definition, are >> executable files supposed to be relocatable? Or we are just trying to >> do some hack by treating an R_386_32 type relocation as R_386_RELATIVE >> effectively. > > If they are supposed to be relocatable? No idea. I mean - my patch is > just asking the linker to keep the relocation information in the > files, right? Then if some external tool (like kexec) is using the > information to relocate the file, how bad can that be? > > Isn't the difference between R_386_32 and R_386_RELATIVE that the > latter is a PC-relative addressing mode? The addressing mode and the > relocation type is setup by the compiler I think, and it is only up to > me to follow it to make sure the address is calculated correctly... > >> Thinking aloud, How about compiling the kernel as shared library and then >> performing the relocations in user space at load time instead of runtime. > > I must confess that I know too little about the exact differences > between a shared library and a binary with relocation information to > say anything wise. Why is vmlinux an executable? > > [snip] > >> The assumption that gloabl variable will come before local fails on >> my machine and build fails. > > Eek. I did expect it to fail sooner or later, but not this early. =) > >> Why don't you provide references to local symbols from a fixed global >> symbol like _stext. (Eric did it in the past) > > I thought of doing that, but then I the idea of relocating sections to > different memory segments came to my mind. So maybe a good solution > would be to use the start address of the segment containing the symbol > instead. > >> I put following code to progress through the build. >> >> for (i = 0; i < table_cnt; i++) { >> - printf("\tPTR\t%#llx\n", table[i].addr); >> + if ((toupper(table[i].sym[0]) != 'A') && >> + (table[i].addr - _stext > 0)) { >> + printf("\tPTR\t_stext + %#llx\n", >> + table[i].addr - _stext); >> + } else { >> + printf("\tPTR\t%#llx\n", table[i].addr); >> + } > > I will have a look at this later on today. Thanks for the suggestion. > >> >> I am still trying to make this patch set work on my machine. > > 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) Eric _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
