Hi, On Thu, 25 Jun 2009, Jeff Mahoney wrote:
I tested it by changing the INITCALLS macro in include/asm-generic/vmlinux.lds.h to issue individual sections. I had to add initcalls.{start,end} sections to contain the pointers describing the boundaries of the initcalls too.
Yes.
Would the initcall sections in the module properly merge into them? Or are we already too late and the relocation records are lost?
... because this is not the case, the modules are .o files, not fully linked, so all relocations are still there.
In the modules, yes. I was wondering about the static image.
Um, wait. You really want to link the module lump together with the static image? That's not going to work easily (or at all) as the static image is fully linked and doesn't contain all necessary relocations anymore to move around its sections (which happens if you insert stuff into the existing ones). So, instead of amending the existing .text section in vmlinux (to contain the merged .text's from the modules) you would have to put this blob into an extra .text2 (for instance) behind all other current sections of vmlinux. You'd have to do that for all sections, essentially being back at attaching the blob simply to the end of vmlinux (with the change that you only have one set of ELF section headers, instead of two, but that's minor). In my mind that module lump would not be linked with the static image, but would rather be sort of a mega-module that is loaded implicitely. It would "somehow" be tacked at the end of vmlinux as blob and then loaded with a only mildly extended module loader (basically everything as now, just that you have multiple this_module sections, and with the difference that the initcall order is split and changed)
I have a script that parses the existing section headers and generates a script with the proper alignment (I hope). Whether it actually works or not, I can't tell yet, since I run into this: ld: vmlinux(.text.head+0xc020000c): reloc against `boot_gdt_descr': error 2
Maybe that's a result of vmlinux already fully linked. Hmm... wasn't it once the case that during building the kernel initially only a merged .o file for everything was generated and that one then again got fully linked? vmlinux.o or something... you could use that.
I'm not sure what's causing that yet.
Seems to be an internal linker error. What's output of 'readelf -rsW vmlinux | grep boot_gdt_descr' (i.e. what type of reloc and symbol is this)? Ciao, Michael. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org