Hi folks,

This patch is to stop the C++ demangler from trying to demangle a symbol
which is not a C++ mangled function.

The problem is happening in Linux/ppc64 with symbols marking the start
of function instructions in the text section, which begin with a dot.
When the function name starts with __, it's symbol will be something
like .__<function name>. If the demangler is able to derive a valid
argument list from <function name>, it will find a demangled "function"
called . with some random argument list. This is happening with several
functions in glibc:

.__frexpf -> .(float, long double,...)(long long, float *)
.__flbf -> .(float, long, bool, float)
.__ffs -> .(float, float, short)
.__ffsll -> .(float, float, short, long, long)
.__sleep -> .(short, long,...)(...)( *)
.__execve -> .(...)(long long,...)(char, void,...)
.__dup -> .(double,  *__restrict)
.__fixdfdi ->  .(float, int, long long, double, float, double, int)
.__fixsfdi -> .(float, int, long long, short, float, double, int)

This is a problem in GDB, for instance when showing a backtrace which
goes through these functions in glibc:

(gdb) bt
#0  0x000004000015edf8 in .__libc_nanosleep () from /lib64/tls/libc.so.6
#1  0x000004000015eb74 in . () from /lib64/tls/libc.so.6
#2  0x0000000010000784 in sleeping_thread (p=0x0) at libc-nanosleep.c:8
(gdb) info symbol 0x000004000015eb74
.(short, long,...)(...)( *) + 148 in section .text

With the patch applied:

(gdb) bt
#0  0x000004000015edf8 in .__libc_nanosleep () from /lib64/tls/libc.so.6
#1  0x000004000015eb74 in .__sleep () from /lib64/tls/libc.so.6
#2  0x0000000010000784 in sleeping_thread (p=0x0) at libc-nanosleep.c:8
(gdb) info symbol 0x000004000015eb74
.__sleep + 148 in section .text

All the libiberty and GDB tests related to demangling continue to pass.

Is this ok?
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center