-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Matz wrote:
Hi,
On Wed, 24 Jun 2009, Jeff Mahoney wrote:
iterates over all of them in order. The linker script can make sure that all these .initcall sections are lying next to each other (i.e. just remain separate in the ELF section list), so that the current code doesn't even need to be changed, if I'm reading it right. The linker script does this now, but it also consolidates them into one .initcall section. AFAIK the only down side to not consolidating it anymore is using extra ELF header space.
Exactly.
I've only looked at a few arches, but it looks like we don't use the section headers for freeing the initmem.
Right, AFAICS (and I have looked at even less arches :) ) the initcall walker is driven just by the _initcall_start and _initcall_end symbols, not by section headers.
Yep.
all things in module-lump will run after vmlinux things of the same level L. If that isn't wanted you need to introduce a new level L-0.5 for the module-lump things, at voila, they are run before the vmlinux things at level L. How much trouble would we run into if we kept the original initcall sections in vmlinux?
Into none I would think ...
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.
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.
Yes, understood. I don't see why that wouldn't be possible with the lumping together anymore, under the condition that modules will contain the original initcall sections in the future. And this bit is trivial. I already have a patch doing that on my development node.
The big problem I've been running into is wrangling the complex linker script into something we can use for the secondary linking.
So, what's the nature of the problem? Just wrapping your head around the many sections and ALIGN directives, or something principle as in "result doesn't work and I don't know why"? Theoretically (as the sections
Initially I was just going to reuse the original linker scripts, but since there is consolidation of sections, it ends up not working as well as expected. 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 I'm not sure what's causing that yet.
of .ko have all the right attributes already) all that should be needed is "ld -r -o lump.ko input1.ko input2.ko ...". This currently fails because of multiply defined symbols on at least __mod_pci_device_table, init_module and cleanup_module. That must be solved in module build time or by renaming symbols. Probably making them static is the right way, a pointer to those functions is already embedded in the this_module section.
Another problem will be the .gnu.linkonce.this_module sections. ld -r will simply select one of the input ones, and not merge them. That requires probably renaming this section (I have no idea why it is linkonce anyway, kernel modules are .o files, not fully linked, so there is only ever one copy of each section, with or without linkonce marking).
I've been planning on unconditionally generating the .initcall*.init section for every module (static or not) and keeping the .gnu.linkonce.this_module section only until we link with the static image.
It seems that currently __mod_pci_device_table is not referred to via some pointer in some module descriptor, but rather explicitely by symbol name in the loader. That's not going to work as when you lump multiple modules together you would have multiple of those. I would embed a pointer to that table into the module descriptor.
We don't need that either. The device table is pointed at by the driver struct, which is registered in the initcall. The __mod_pci_device_table, I think, is only used to generate the aliases for automatic loading. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkpDifkACgkQLPWxlyuTD7Im/wCeIYGNI0i69XkacPY6HnTXkkxo yH8An27qyeJDPZRarl16/DAnMvbu1HE5 =zCZY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org