Mailinglist Archive: opensuse-kernel (59 mails)

[Jeff Mahoney <jeffm@xxxxxxxx>]

-----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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kernel+help@xxxxxxxxxxxx