[PATCH] Regression setting breakpoint
Michael Eager
eager@eagerm.com
Fri Jan 31 16:21:00 GMT 2014
Ping.
Any comments?
On 12/11/13 12:38, Michael Eager wrote:
> 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.
>
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
More information about the Gdb-patches
mailing list