List Info

Thread: Fix PR debug/33155: Don't add DW_AT_MIPS_linkage_name for C functions




Fix PR debug/33155: Don't add DW_AT_MIPS_linkage_name for C functions
user name
2008-04-26 17:26:47
The attached fixes GCC bug
htt
p://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155

by preventing the addition of DW_AT_MIPS_linkage_name for C
functions.
On MS Windows targets, the external assembler name of
__stdcall functions are
mangled in  C as well as C++ by the addition of an 'n'
suffix.
GDB however does not appear to  handle
DW_AT_MIPS_linkage_name for C functions.

Should this be addressed in gdb sources rather than in GCC?

Tested on i686-pc-mingw32 with GNU gdb 6.5.50.20060706-cvs
(cygwin-special) .

2008-04-27  Danny Smith  <dannysmithusers.sourforge.net>

	PR debug/33155
        * 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 134695)
+++ dwarf2out.c	(working copy)
 -4190,6
+4190,7 
 static unsigned get_AT_unsigned (dw_die_ref, enum
dwarf_attribute);
 static inline dw_die_ref get_AT_ref (dw_die_ref, enum
dwarf_attribute);
 static bool is_c_family (void);
+static bool is_c (void);
 static bool is_cxx (void);
 static bool is_java (void);
 static bool is_fortran (void);
 -5570,6
+5571,17 
 	  || lang == DW_LANG_C_plus_plus || lang ==
DW_LANG_ObjC_plus_plus);
 }

+/* 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 || lang == DW_LANG_ObjC);
+}
+
 /* Return TRUE if the language is C++.  */

 static inline bool
 -11556,7
+11568,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)));
     }

Re: Fix PR debug/33155: Don't add DW_AT_MIPS_linkage_name for C functions
country flaguser name
United States
2008-05-01 19:17:23
On Sun, Apr 27, 2008 at 10:26:47AM +1200, Danny Smith
wrote:
> The attached fixes GCC bug
> htt
p://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155
> 
> by preventing the addition of DW_AT_MIPS_linkage_name
for C functions.
> On MS Windows targets, the external assembler name of
__stdcall functions are
> mangled in  C as well as C++ by the addition of an
'n'
suffix.
> GDB however does not appear to  handle
DW_AT_MIPS_linkage_name for C functions.
> 
> Should this be addressed in gdb sources rather than in
GCC?

GDB's reliance on DW_AT_MIPS_linkage_name is somewhat
dubious in
general.  The way GCC is using it sounds correct, or as
close to that
as you get for something with no written specification.  I
have
patches to improve GDB's behavior but meanwhile I don't see
any harm
in this patch.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Fix PR debug/33155: Don't add DW_AT_MIPS_linkage_name for C functions
country flaguser name
United States
2008-05-07 12:24:49
Daniel Jacobowitz wrote:
> On Sun, Apr 27, 2008 at 10:26:47AM +1200, Danny Smith
wrote:
>> The attached fixes GCC bug
>> htt
p://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155
>>
>> by preventing the addition of
DW_AT_MIPS_linkage_name for C functions.
>> On MS Windows targets, the external assembler name
of __stdcall functions are
>> mangled in  C as well as C++ by the addition of an
'n'
suffix.
>> GDB however does not appear to  handle
DW_AT_MIPS_linkage_name for C functions.
>>
>> Should this be addressed in gdb sources rather than
in GCC?
> 
> GDB's reliance on DW_AT_MIPS_linkage_name is somewhat
dubious in
> general.  The way GCC is using it sounds correct, or as
close to that
> as you get for something with no written specification.
 I have
> patches to improve GDB's behavior but meanwhile I don't
see any harm
> in this patch.

Has this patch been tested by running the GDB testsuite on a
non-Windows 
target?  (For example, an embedded simulator target, or x86
GNU/Linux?) 
  If there are no regressions, then this is OK.

Thanks,

-- 
Mark Mitchell
CodeSourcery
markcodesourcery.com
(650) 331-3385 x713

[1-3]

about | contact  Other archives ( Real Estate discussion Medical topics )