There is a regression when setting a breakpoint which was introduced
in gdb-7.3 by a fix in this patch:
https://sourceware.org/ml/gdb-patches/2010-03/msg00220.html
The regression shows up in C when the linkage name is different
from the internal symbol name. For example,
void goo (int b) asm("_goo");
void goo (int b) {}
will create a function with the linkage name of "_goo" and the DWARF
will describe the source name of "goo". There is both a DW_AT_name and
DW_AT_linkage_name in the DIE for this function. Some compilers
(e.g., ICC) have options allowing linkage names to have characters
prepended to the source name so that the linkage name is different
from the source name and can not be computed from it.
Prior to this patch, a breakpoint at "_goo" would find the linkage
symbol, and one at "goo" would find the source symbol. After the
patch, the source name is replace with the linkage name.
The attached patch fixes this by making die_needs_namespace()
return 0 for any C language program. There's also a test case.
I'm not sure that this is the right fix for the problem, although
I'm pretty sure that it should not break anything. There is code
in dwarf2_compute_name() which only calls die_needs_namespace()
for C++, Java, or Fortran programs, which could be moved into
die_needs_namespace(). Possibly the fix should be in dwarf2_physname()
where the call to die_needs_namespace() is done before the check for
DW_AT_linkage_name is done.
Comment: Much of the code in dwarf2_compute_name(), dwarf2_physname(),
and related functions seems complex, convoluted, and confusing (the
big Three C's). The source name for a symbol is not the same as
the fully qualified name and it's not the same as the linkage name.
That a language supports FQNs with namespaces does not seem to me
to say that this should have anything to do with what the linkage (aka
physical) name for the symbol is.