On Tue, 11 Jul 2006 01:32:19 +0200, Vivek Goyal wrote:
...
> 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.
Maybe, I can't much argue with it. The relevant sections of
http://x86.ddj.com/ftp/manuals/tools/elf.pdf
use the word "typically" while IMO not prohibiting relocatable executables.
...
> 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.
Yes, as in this stage of the build process the sections are already in fact
fixed and they are immediately converted to the "binary" format in the next
build stage making R_386_RELATIVE the valid (virtual) relocation type.
> 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.
OK, so not to be hackish you would like interstage between
arch/i386/boot/compressed/vmlinux
(ELF still containing .text, .rodata, .data etc.,
possibly incl. the relocations)
and
arch/i386/boot/compressed/vmlinux.bin
(binary no longer containing any relocations)
so that it would be still ELF (and thus capable containing relocation tables)
while all sections would be already merged (to make R_386_RELATIVE possible
there).
(This interstage would possibly replace the existing
"arch/i386/boot/compressed/vmlinux" stage.)
I feel no one of us understands all the details of the relocations perfectly
enough. I find in my Fedora Core 5 that "/lib/libc.so.6" still contains all the
sections while it has only R_386_RELATIVE relocations which looks to me as the
same type of problem you are objecting to the build interstage of mkdump-2.0+.
I had to do the job, it worked fine, it was the minimal patch set to the
existing Linux kernel sources, it was foolproof as long as no one messed with
these building stages rules. Maybe you try to be wrongly hypercorrect?
> 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.
It may be possible, just:
(a) I require self-relocatable bzImage bootstrapping (see below).
(b) Current bzImage does not contain any ELF format inside.
(a) && (b) => (c)
(c) You need custom / non-ELF relocation tables.
(c) => (d) || (e) || (f)
(d) You need custom tool to convert ELF relocations to your custom format
(this tool is "scripts/reltab.c").
(e) You need some other simple enough non-ELF general executable format
and use binutils built supporting this file format.
(f) You would need to implement your custom relocation tables format to the
list of supported binary formats by binutils.
(e) || (f) => (g)
(g) You cannot expect the system-installed binutils to support anything
besides ELF so you would have to bundle binutils with Linux kernel etc.
I chose (d).
...
> 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).
Because I want self-relocatable bzImage. I want simplicity.
The current bzImage must be loaded at 0x100000 as otherwise it crashes.
mkdump-2.0+ bzImage can be loaded to any address you wish and in a way backward
compatible with any existing Linux kernel loaders it can run either from the
legacy 0x100000 startup address or it will automatically detect any other
address and gets running fine on its own.
...
> 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?
I do not like the requirement of the user-space relocating as I feel it as
a workaround of Linux kernel failing to be bootstrapped from arbitrary address.
I find the extension of existing bootstrapping code to just clean up this bug.
Still you need somehow to store the relocation tables to the "bzImage" file
where are no longer any ELF structures available. So you need to do the
decision where I personally chose (d) and thus there is still the need for some
"scripts/reltab.c". BTW "reltab.c" is really userland. :-)
Anyway there are many methods how to do it and most of them are acceptable,
Linux kernel has much more serious design flaws than just some bootstrapping.
And regarding what is kernelland and what is userland, I have some more radical
(microkernel) view of it but it is definitely out of scope of kexec et al.
Regards,
Lace
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot
