> You write:
> | Meanwhile, I've been working on v0.6 of kdb for 2.2.13 and
> | am reorganizing kdb sources to split into machine dependent and
> | machine independent parts, with rudimentary mips and itanium support, which
> | will become version v1.0 of kdb and will be relative to the
> | 2.3 series kernels.
>
> I'd like to urge a change in how kdb-enabled kernels currently build.
> In the kdb-v0.5-2.2.10 patch, you always reserve a fixed amount of
> space in kern/arch/i386/vmlinux.lds for kdb symbols. As I understand
> it, this is so you can easily get the addresses of the kernel symbols:
> link the kernel once, pull the symbols out, and relink -- you know
> that because the space reserved for the symbol table is fixed, the
> symbols won't change address between builds.
>
> Unfortunately, I believe that this approach has two deleterious
> consequences:
> - if you have too many symbols, or too long symbols (such as if you
> turn on CONFIG_MODVERSIONS) you can overflow the assigned space;
> the resulting kernel builds without error but will probably crash
> instantly on boot.
With the v0.6, which I've been using internally, the max number of
symbols is a configurable option, and the default is much larger
(9000). With the AC12 patches to 2.2.10, the vmlinux.lds file
is now run through cpp so the space reservation can be conditioned
on CONFIG_KDB and the amount reserved can be based upon
CONFIG_KDB_STBSIZE, which is better than v0.5.
For v1.0 (which will be against the 2.3 kernel series), I'll look at
finding a better way. I've several suggestions from various folks
to look at.
> - because the space reservation is independant of whether CONFIG_KDB
> is turned on, adding the kdb patch to your kernel is not a cost-free
> thing if you never turn it on; you always eat up 192K or so of kernel
> space. This makes it unsuitable for adding the patch to general
> kernel distributions (or keeping in a local kernel), which I think
> is a pity.
See above - vmlinux.lds is preprocessed which eliminates this issue.
>
> I'd like to suggest that you eliminate the fixed symbol table space and
> move kdb-enabled kernels to a three-link approach, where the first link
> lets you count how many symbols there are to accurately size the symbol
> table space, the second link generates the correct data for the symbols,
> and the third glues everything together correctly. (Hmm. I wonder if
> there's some way to use the binutils ELF tools to just shove the symbol
> data into the vmlinux file without actually bothering to relink, since
> the only job of the third relink is to do basically that.)
I'll keep this approach in mind for v1.0.
thanks,
scott
>
> ---
> "I shall clasp my hands together and bow to the corners of the world."
> Number Ten Ox, "Bridge of Birds"
> cks@xxxxxxxxxxxxxxxx utgpu!cks
>
|