>I don't think it's a good idea to have two different ways >to do kallsyms. Either we should always use your new >way in standard KALLSYMS or not do it at all.
I agree, but I wanted to retain the old mechanism not the least because of the space constraints you mention. >The major decision factor is how much bloat it adds. >Can you post before/after numbers of binary size? i386 vmlinux KALLSYMS_ALL=n: old=5782934 new=6106675 (5.60% increase) i386 vmlinux KALLSYMS_ALL=y: old=6049118 new=6524411 (7.85% increase) x86-64 vmlinux KALLSYMS_ALL=n: old=8593125 new=8962128 (4.30% increase) x86-64 vmlinux KALLSYMS_ALL=y: old=8797853 new=9117704 (3.64% increase) I shall note additionally that not using KALLSYMS_ALL with the new approach increases the build time somewhat because the stripping of the data symbols in this scheme is rather inefficient (a binutils limitation as I would call it). KALLSYMS_ALL=y, however, is mostly suited for kernel debugging, while KALLSYMS_ALL=n seems the best choice if just caring about symbolic stack traces, which seems to be another argument for keeping both mechanisms. >If the difference is >5% or so - are there ways to recover >the difference? There are certainly ways, but I'm not sure how much they would cost. One thing would be to teach the linker to not only optimize the section string table, but also the (normal) symbol string one. Decreasing the symbol table size might be more difficult - only st_size and only on 64-bit archs seems to lend itself to reduction (as any symbol's size can clearly be expected to be less than 4G). But that would result in alignment problems, so I don't think that'd be a good idea either. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
