My patch: 2007-05-24 Danny Smith <dannysmith@users.sourceforge.net> PR target/27067 * doc/tm.texi (TARGET_MANGLE_DECL_ASSEMBLER_NAME): Document. * targhooks.h (default_mangle_decl_assembler_name): Declare default hook. * targhooks.c (default_mangle_decl_assembler_name): Define default hook. * target-def.h (TARGET_MANGLE_DECL_ASSEMBLER_NAME) New. Set to default hook. * target.h (struct gcc_target): Add mangle_decl_assembler_name field. * langhooks.c (lhd_set_decl_assembler_name): Call targetm.mangle_decl_assembler_name for names with global scope. breaks gdb usage for setting breakpoints on __stdcall functions in C (but not C++) The problem appear to derive from a difference between the DECL_NAME and DECL_ASSEMBLER_NAME which was introduced by the patch. Windows targets decorate stdcall assembler identifiers with an @n suffix. Before this patch, the assembler decoration was only added to RTL names in encode_section_info; after the patch the decoration is added upfront to DECL_ASSEMBLER_NAME, because the extern assembler name is really the decorated name. Here is an example: =================== /* foo.c */ int __stdcall bar() { return 1; } int main() { return bar(); } =================== Compiling with gcc -g -xc foo.c then C:\develop\bugs>gdb a GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you ar welcome to change it and/or distribute copies of it under certain condition Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) break bar Function "bar" not defined. However, there are no problems in C++ where there is also (and because of name mangling, generally) a difference between the the DECL_NAME and the DECL_ASSEMBLER_NAME. compiling with gcc -g -xc++ foo.c then C:\develop\bugs>gdb a GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) break bar Breakpoint 1 at 0x4013a3: file foo.c, line 3. Reverting this part of the patch * langhooks.c (lhd_set_decl_assembler_name): Call targetm.mangle_decl_assembler_name for names with global scope. avoids the C debugging problem. gdb knows how to handle C++ mangling diffs between DECL_NAME and DECL_ASSEMBLER_NAME, so the C++ part of the patch: * cp/mangle.c (mangle_decl): Call targetm.mangle_decl_assembler_name. doesn't cause any problems. Danny
What is the status on this? Does reverting the langhooks.c change remanifest PR27067?
(In reply to comment #1) > What is the status on this? Does reverting the langhooks.c change remanifest > PR27067? > No. PR27067 is fixed by cp/mangle.c (mangle_decl): Call targetm.mangle_decl_assembler_name. Danny
(In reply to comment #2) > (In reply to comment #1) > > What is the status on this? Does reverting the langhooks.c change remanifest > > PR27067? > > > No. PR27067 is fixed by > cp/mangle.c (mangle_decl): Call targetm.mangle_decl_assembler_name. I see; then should the langhooks.c bit be reverted to fix this bug, or do you think it will be able to be solved soon some other way?
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > What is the status on this? Does reverting the langhooks.c change remanifest > > > PR27067? > > > > > No. PR27067 is fixed by > > cp/mangle.c (mangle_decl): Call targetm.mangle_decl_assembler_name. > > I see; then should the langhooks.c bit be reverted to fix this bug, or do you > think it will be able to be solved soon some other way? > I don't know how to solve it. I thought it might be a GDB bug concerning DW_AT_MIPS_linkage_name and an assumption by GDB that "C" assembler names are not mangled, but I haven't had time to follow up. But on windows, the external DECL_ASSEMBLER_NAME for stdcall symbols look mangled to me, in C as well as C++, and gcc/dwarf2out.c:add_name_and_src_coords_attributes() does the right thing. But ,as I said, I haven't had time to study GDB. Danny I
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > (In reply to comment #1) > > > > What is the status on this? Does reverting the langhooks.c change remanifest > > > > PR27067? > > > > > > > No. PR27067 is fixed by > > > cp/mangle.c (mangle_decl): Call targetm.mangle_decl_assembler_name. > > > > I see; then should the langhooks.c bit be reverted to fix this bug, or do you > > think it will be able to be solved soon some other way? > > > > I don't know how to solve it. I thought it might be a GDB bug concerning > DW_AT_MIPS_linkage_name and an assumption by GDB that "C" assembler names are > not mangled, but I haven't had time to follow up. But on windows, the external > DECL_ASSEMBLER_NAME for stdcall symbols look mangled to me, in C as well as > C++, and gcc/dwarf2out.c:add_name_and_src_coords_attributes() does the right > thing. > > But ,as I said, I haven't had time to study GDB. > Danny > Huh, it is quite easy to ensure the old gdb assumptions about GNU C name mangling. This fixes the PR testcase for me, with GNU gdb 6.5.50.20060706-cvs (cygwin-special). GCC "make check" is in progress. * dwarf2out.c (is c): New function. (add_name_and_src_coords_attributes): Don't add DW_AT_MIPS_linkage_name if is_c (). Index: dwarf2out.c =================================================================== --- dwarf2out.c (revision 134429) +++ dwarf2out.c (working copy) @@ -5558,6 +5558,15 @@ return a ? AT_file (a) : NULL; } +/* Return TRUE if the language is C. */ +static inline bool +is_c (void) +{ + unsigned int lang = get_AT_unsigned (comp_unit_die, DW_AT_language); + + return (lang == DW_LANG_C || lang == DW_LANG_C89 || lang == DW_LANG_C99); +} + /* Return TRUE if the language is C or C++. */ static inline bool @@ -11558,7 +11567,7 @@ && DECL_ASSEMBLER_NAME (decl) != DECL_NAME (decl) && !DECL_ABSTRACT (decl) && !(TREE_CODE (decl) == VAR_DECL && DECL_REGISTER (decl)) - && !is_fortran ()) + && !is_fortran () && !is_c ()) add_AT_string (die, DW_AT_MIPS_linkage_name, IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl))); }
Patch submitted at http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01977.html Danny
This is fixed in 4.5.0 release. http://gcc.gnu.org/viewcvs?view=revision&revision=148199 Danny
(In reply to Danny Smith from comment #7) > This is fixed in 4.5.0 release. > > http://gcc.gnu.org/viewcvs?view=revision&revision=148199 > > Danny So, I guess it can be closed as FIXED then.