[Bug debug/33155] New: _stdcall assembler names in win32 vs gdb

[Bug debug/33155] New: _stdcall assembler names in win32 vs gdb

[dannysmith at users dot sourceforge dot net]

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


-- 
           Summary: _stdcall assembler  names in win32  vs gdb
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dannysmith at users dot sourceforge dot net
 GCC build triplet: i386-pc-mingw32
  GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155

[Bug debug/33155] _stdcall assembler names in win32 vs gdb

[aaronavay62 at aaronwl dot com]

------- Comment #1 from aaronavay62 at aaronwl dot com  2008-04-13 19:48 -------
What is the status on this?  Does reverting the langhooks.c change remanifest
PR27067?


-- 

aaronavay62 at aaronwl dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aaronavay62 at aaronwl dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155

[Bug debug/33155] _stdcall assembler names in win32 vs gdb

[dannysmith at users dot sourceforge dot net]

------- Comment #2 from dannysmith at users dot sourceforge dot net  2008-04-26 03:17 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155

[Bug debug/33155] _stdcall assembler names in win32 vs gdb

[aaronavay62 at aaronwl dot com]

------- Comment #3 from aaronavay62 at aaronwl dot com  2008-04-26 04:13 -------
(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?


-- 

aaronavay62 at aaronwl dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-04-26 04:13:31
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155

[Bug debug/33155] _stdcall assembler names in win32 vs gdb

[dannysmith at users dot sourceforge dot net]

------- Comment #4 from dannysmith at users dot sourceforge dot net  2008-04-26 07:23 -------
(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 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155

[Bug debug/33155] _stdcall assembler names in win32 vs gdb

[dannysmith at users dot sourceforge dot net]

------- Comment #5 from dannysmith at users dot sourceforge dot net  2008-04-26 08:24 -------
(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)));
     }


-- 

dannysmith at users dot sourceforge dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dannysmith at users dot
                   |                            |sourceforge dot net
         AssignedTo|unassigned at gcc dot gnu   |dannysmith at users dot
                   |dot org                     |sourceforge dot net
             Status|NEW                         |ASSIGNED
      Known to fail|                            |4.3.0
      Known to work|                            |4.2.1
   Last reconfirmed|2008-04-26 04:13:31         |2008-04-26 08:24:46
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155

[Bug debug/33155] _stdcall assembler names in win32 vs gdb

[dannysmith at users dot sourceforge dot net]

------- Comment #6 from dannysmith at users dot sourceforge dot net  2008-04-26 22:29 -------
Patch submitted at 
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01977.html
Danny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155

[Bug debug/33155] _stdcall assembler names in win32 vs gdb

[dannysmith at users dot sourceforge dot net]

------- Comment #7 from dannysmith at users dot sourceforge dot net  2010-04-26 08:19 -------
This is fixed in 4.5.0  release.

http://gcc.gnu.org/viewcvs?view=revision&revision=148199 

Danny


-- 

dannysmith at users dot sourceforge dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|4.2.1                       |4.2.1 4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155