Re: [PATCH] kallsyms, tracing: output more proper symbol name

From: Paulo Marques
Date: Wed Mar 11 2009 - 10:27:24 EST


Ingo Molnar wrote:
> * Lai Jiangshan <laijs@xxxxxxxxxxxxxx> wrote:
>
>> +#define VMLINUX_SYMBOL(_sym_) #_sym_
>> +
>> +static const char *hide_symbols[] = {
>> + /* misc symbols */
>> + "_text",
>> + "_stext",
>> + "_etext",
>> + "_sinittext",
>> + "_einittext",
>> +
>> + /* symbols from include/asm-generic/vmlinux.lds.h */
>> + VMLINUX_SYMBOL(__start_mcount_loc),
>> + VMLINUX_SYMBOL(__stop_mcount_loc),
[...]
>> + VMLINUX_SYMBOL(__early_initcall_end),
>> + VMLINUX_SYMBOL(__per_cpu_start),
>> + VMLINUX_SYMBOL(__per_cpu_end)
>> +};
>
> I like how you try to solve this at symbol table generation
> time.

Yes, this is the proper way to do it.

> Instead of this hardcoded table, couldnt we use some more
> flexible and more future-proof method? Such as ordering
> same-address symbols by underscores:
>
> [same address]
>
> non-underscore symbols first XYZ
> single-undescroe symbols second _XYZ
> double-underscore symbols third __XYZ
>
> that way the scheme would be more or less self-maintaining as an
> underscore already carries a "this is a special, internal
> symbol" notion.

I agree with this approach, but to be on the side we should skim through
the alias and see if this works for most symbols or not.

I just did this for the symbols on my running kernel and it seems to
work. The hierarchy for '_' and '__' is in fact necessary:

> ffffffff80447418 T __sched_text_start
> ffffffff80447418 t sleep_on_common
> ffffffff80449830 T __lock_text_start
> ffffffff80449830 T __sched_text_end
> ffffffff80449830 T _spin_trylock
> ffffffff80453d50 R __stop___ex_table
> ffffffff80453d50 T __start_notes
> ffffffff8045b000 R __start_rodata
> ffffffff8045b000 R linux_banner

or that "_spin_trylock" might be displayed incorrectly as
"__sched_text_end" or something like that.

--
Paulo Marques - www.grupopie.com

"Who is general Failure and why is he reading my disk?"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/