GCC Bugzilla Bug 33155

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