Mailing List Archive: [PATCH 1/39] NLKD - an alternative kallsyms approach

[PATCH 1/39] NLKD - an alternative kallsyms approach

Nov 9, 2005, 5:56 AM

Post #1 of 4 (183 views)

This patch provides an alternative to the pre-exisiting kallsyms code.
That code, from a kernel debugger perspective at least, suffers from
incomplete information, making it impossible to
(a) disambiguate multiple static functions of the same name (in
different source files),
(b) determine a complete set of attributes for a symbol (namely, the
symbol's size, but also its type, which gets converted to an nm-like
one-character representation), and
(c) retain full section information

This new approach basically makes handling core kernel and module
symbols the same, by retrieving the kernel's section, symbol, and
string tables rather than parsing the system map.

At once it adds the functionality to strip unneeded symbols from
modules, which results in non-neglectable space savings for typical
distributions (which large amounts of modules). Note that with certain
recent, but broken binutils versions (2.16.90*, 2.16.91* up to
and including 2.16.91.0.3) this can only be built without
CONFIG_MODVERSIONS.

Signed-Off-By: Jan Beulich <jbeulich@novell.com>

(actual patch attached)

Re: [PATCH 1/39] NLKD - an alternative kallsyms approach [ In reply to ]

rdunlap at xenotime

Nov 9, 2005, 8:50 AM

Post #2 of 4 (176 views)

Permalink

On Wed, 9 Nov 2005, Jan Beulich wrote:

> This patch provides an alternative to the pre-exisiting kallsyms code.
> That code, from a kernel debugger perspective at least, suffers from
> incomplete information, making it impossible to
> (a) disambiguate multiple static functions of the same name (in
> different source files),
> (b) determine a complete set of attributes for a symbol (namely, the
> symbol's size, but also its type, which gets converted to an nm-like
> one-character representation), and
> (c) retain full section information
>
> This new approach basically makes handling core kernel and module
> symbols the same, by retrieving the kernel's section, symbol, and
> string tables rather than parsing the system map.
>
> At once it adds the functionality to strip unneeded symbols from
> modules, which results in non-neglectable space savings for typical
> distributions (which large amounts of modules). Note that with certain
> recent, but broken binutils versions (2.16.90*, 2.16.91* up to
> and including 2.16.91.0.3) this can only be built without
> CONFIG_MODVERSIONS.
>
> Signed-Off-By: Jan Beulich <jbeulich@novell.com>
>
> (actual patch attached)

It's still not a text-type attachment...

BTW, are you posting these just for comments or did you want
someone to apply/merge them? If so, who? You should send them
to that someone (unless you have some other arrangements) --
at least that's the normal procedure.

--
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 1/39] NLKD - an alternative kallsyms approach [ In reply to ]

greg at kroah

Nov 9, 2005, 8:57 AM

Post #3 of 4 (180 views)

Permalink

On Wed, Nov 09, 2005 at 08:50:15AM -0800, Randy.Dunlap wrote:
> BTW, are you posting these just for comments or did you want
> someone to apply/merge them? If so, who? You should send them
> to that someone (unless you have some other arrangements) --
> at least that's the normal procedure.

And the documented one too, see Documentation/SubmittingPatches, section
5.

Why does no one ever read the documentation...

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 1/39] NLKD - an alternative kallsyms approach [ In reply to ]

JBeulich at novell

Nov 9, 2005, 9:20 AM

Post #4 of 4 (179 views)

Permalink

>BTW, are you posting these just for comments or did you want
>someone to apply/merge them? If so, who? You should send them
>to that someone (unless you have some other arrangements) --
>at least that's the normal procedure.

I don't expect the debugger itself to be merged, but I hope the
preparatory pieces could be. And then, if not Andrew (who, as far as I
can see, picks up things from the list just as much as stuff directly
addressed to him), who would I send this to? There's doesn't seem to be
a clear maintainer of i386, for example, and that seems to be the case
for many other parts, too.

Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Mailing List Archive

Mailing List Archive

Attached Files: