On Fri, Jul 07, 2006 at 04:35:19PM +0200, Jan Kratochvil wrote: > Hi, > > On Fri, 07 Jul 2006 15:35:18 +0200, Vivek Goyal wrote: > ... > > I think --emit-relocs is just emitting relocations which have already > > been processed. In your approach you are just taking a clue where all > > relocations have been applied in this executable file and try to > > relocate. As I said previously, you are effectively chaning the type of > > relocation. > > 1. The type of relocation is NOT changed after --emit-relocs (and it would > still be a bug in ld(1), not in mkdump).
> The output from --emit-relocs still contains the symbol names and contains > still valid R_386_32 relocations (you can shift each section to a different > address and still update all the relocations properly). The linking > process > just adjusted the addends (A) to the new linked base address of the > executable. > I think there is some misunderstanding. --emit-relocs is fine. The only issue is that you are trying to relocate an executable. AFAIK, the by definition, executables are not supposed to be relocated and their execution address is fixed. --emit-relocs is just emitting already processed relocations and you are just taking a clue from linker generated relocations and applying your own relocations to make this executable run from a different address. Magnus's implementation does this thing. If relocation type is (S+A), he ignores that and replaces the symbol value (S) with displacement (adj) instead of reading symbol value from the symbol table. I quickly went through your mkdump reltab based implementation as well and my limited understanding says that you are also doing the similar thing. From linker generated relocation entries you take a clue and generate your own relocation tables and apply your own relocations. For exaplme, reltab relocation "relocate32plus" is just adding the offset by which new kernel image has been displaced which is effectively equivalent to applying relocation type R_386_RELATIVE. So basically my point is that by using --emit-relocs, we are taking clue from where all relocations should be applied. After that we do some guess work and apply our own relocations type and ignore the relocations type as generated by linker, which kind of looks little hackish. Why don't we look into the approach of using "--shared" or "--pic-executable" so that linker we apply same relocation types as generated by linker. (I am sure we shall run into the issues like absolute symbols etc, which probably can be resolved). > 2. I was speaking for mkdump which does not fiddle with any ELF and > --emit-relocs is only a building stage for it - so it is a bit irrelevant. > mkdump-2.0+ uses its own trivia raw binary relocation tables as described > in > the second comment "Output file layout" of: > > http://mkdump.cvs.sourceforge.net/mkdump/linux/scripts/reltab.c?view=markup&pathrev=linux-2_6-minik > > I am still trying to understand that why are you generating your own relocation tables. Why don't you delegate this job to linker (As Eric had done in his "-shared" implementation). > I cannot comment on it as I still have no clue of your goals. I still do not > understand why to have ELF (so different format than bzImage) mini-kernel. > After the primary kernel starts to be ELF (the same format), I will be glad to > continue this discussion. > Initially I was thinking of relocating an ELF image and assumed that distro's will also provide a vmlinux file along with bzImage. After looking at mkdump implementation I liked the idea of keeping relocation information in raw binary and using that information at execution time to relocate the kernel. Going through the archive, I remember you also mentioned that you got a propriteary utility to extract raw binary (vmlinux.bin) from bzImage. So here is what I am thinking that, build a kernel with either "-shared" or "-pie" and then retain the relocation information in generated raw binary, vmlinux.bin (It seems for shared libraries, "objcopy -S" is retaining this information and not getting rid of relocation section, rel.dyn). Write a utility to extract raw binary from bzImage (Hoping it is possible) and perform the relocations from user space and load the relocated binary. Extraction and relocation shall be done in user space (kexec) to keep the thins simple and easier and we can get rid of all the code in "scripts/reltab.c". Anyway, as of today there does not seem to be any user of relocation except kdump. What do you think of above? Thanks Vivek _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
