RFA: strip stdcall suffixes under Cygwin

RFA: strip stdcall suffixes under Cygwin

[Jim Blandy]

Chris, I think I need your approval for this.

2002-03-27  Jim Blandy  <jimb@redhat.com>

	* config/i386/tm-cygwin.h: #define
	LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES.
	* symtab.c (LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES): Provide
	default #definition here, if tm-*.h file doesn't have one.
	(symbol_init_mangled_name): If the above is #defined, strip off
	the stdcall arg size, if present, from linker symbol names before
	trying to demangle them.

Index: gdb/symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.59
diff -c -r1.59 symtab.c
*** gdb/symtab.c	2002/03/27 23:10:23	1.59
--- gdb/symtab.c	2002/03/27 23:19:07
***************
*** 353,358 ****
--- 353,362 ----
  \f
  /* Initialize a symbol's mangled name.  */
  
+ #ifndef LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES
+ #define LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES (0)
+ #endif
+ 
  /* Try to initialize the demangled name for a symbol, based on the
     language of that symbol.  If the language is set to language_auto,
     it will attempt to find any demangling algorithm that works and
***************
*** 369,381 ****
    char *mangled = gsymbol->name;
    char *demangled = NULL;
  
    if (gsymbol->language == language_unknown)
      gsymbol->language = language_auto;
    if (gsymbol->language == language_cplus
        || gsymbol->language == language_auto)
      {
        demangled =
!         cplus_demangle (gsymbol->name, DMGL_PARAMS | DMGL_ANSI);
        if (demangled != NULL)
          {
            gsymbol->language = language_cplus;
--- 373,418 ----
    char *mangled = gsymbol->name;
    char *demangled = NULL;
  
+   /* On Windows, some functions use the `stdcall' calling convention,
+      in which the callee is expected to pop the arguments off the
+      stack.  Normally, the caller takes care of this, because only the
+      caller knows how many arguments it really passed.  To avoid
+      confusion, the linker symbols for `stdcall' functions have names
+      with a suffix "@N" attached to them, where "N" is the number of
+      bytes they'll pop.  That way, if a caller thinks some `stdcall'
+      function `foo' expects M argument bytes, but the definition of
+      `foo' expects N argument bytes, N != M, then the call will be a
+      reference to `foo@M', but the definition will have a linker
+      symbol `foo@N', and you'll get a link-time `symbol not found'
+      error, instead of a crash at run-time.
+ 
+      (Note how this fails to address calls through function pointers,
+      since the byte count isn't part of the function pointer's type.
+      Go, Microsoft!)
+ 
+      Whatever.  But our demangler doesn't like that '@N' suffix, so we
+      need to strip it off.  */
+   if (LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES)
+     {
+       char *arg_byte_suffix = strchr (mangled, '@');
+       if (arg_byte_suffix)
+         {
+           int prefix_len = arg_byte_suffix - mangled;
+           char *mangled_sans_suffix = alloca (prefix_len + 1);
+           memcpy (mangled_sans_suffix, mangled, prefix_len);
+           mangled_sans_suffix[prefix_len] = '\0';
+ 
+           mangled = mangled_sans_suffix;
+         }
+     }
+ 
    if (gsymbol->language == language_unknown)
      gsymbol->language = language_auto;
    if (gsymbol->language == language_cplus
        || gsymbol->language == language_auto)
      {
        demangled =
!         cplus_demangle (mangled, DMGL_PARAMS | DMGL_ANSI);
        if (demangled != NULL)
          {
            gsymbol->language = language_cplus;
***************
*** 391,397 ****
    if (gsymbol->language == language_java)
      {
        demangled =
!         cplus_demangle (gsymbol->name,
                          DMGL_PARAMS | DMGL_ANSI | DMGL_JAVA);
        if (demangled != NULL)
          {
--- 428,434 ----
    if (gsymbol->language == language_java)
      {
        demangled =
!         cplus_demangle (mangled,
                          DMGL_PARAMS | DMGL_ANSI | DMGL_JAVA);
        if (demangled != NULL)
          {
Index: gdb/symtab.h
===================================================================
RCS file: /cvs/src/src/gdb/symtab.h,v
retrieving revision 1.29
diff -c -r1.29 symtab.h
*** gdb/symtab.h	2002/03/27 23:10:24	1.29
--- gdb/symtab.h	2002/03/27 23:19:08
***************
*** 159,170 ****
        }									\
    } while (0)
  
  #define SYMBOL_INIT_DEMANGLED_NAME(symbol,obstack) \
    (symbol_init_demangled_name (&symbol->ginfo, (obstack)))
  extern void symbol_init_demangled_name (struct general_symbol_info *symbol,
                                          struct obstack *obstack);
  
-   
  /* Macro that returns the demangled name for a symbol based on the language
     for that symbol.  If no demangled name exists, returns NULL. */
  
--- 159,171 ----
        }									\
    } while (0)
  
+ 
  #define SYMBOL_INIT_DEMANGLED_NAME(symbol,obstack) \
    (symbol_init_demangled_name (&symbol->ginfo, (obstack)))
  extern void symbol_init_demangled_name (struct general_symbol_info *symbol,
                                          struct obstack *obstack);
+ 
  
  /* Macro that returns the demangled name for a symbol based on the language
     for that symbol.  If no demangled name exists, returns NULL. */
  
Index: gdb/config/i386/tm-cygwin.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-cygwin.h,v
retrieving revision 1.11
diff -c -r1.11 tm-cygwin.h
*** gdb/config/i386/tm-cygwin.h	2001/11/27 05:15:58	1.11
--- gdb/config/i386/tm-cygwin.h	2002/03/27 23:19:12
***************
*** 47,49 ****
--- 47,51 ----
  char *child_solib_loaded_library_pathname(int);
  void child_clear_solibs (void);
  void dll_symbol_command (char *, int);
+ 
+ #define LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES (1)

Re: RFA: strip stdcall suffixes under cygwin

[Christopher Faylor]

On Wed, Mar 27, 2002 at 06:35:25PM -0500, Jim Blandy wrote:
>Chris, I think I need your approval for this.

Approved.

Thanks,
cgf

>2002-03-27  Jim Blandy  <jimb@redhat.com>
>
>	* config/i386/tm-cygwin.h: #define
>	LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES.
>	* symtab.c (LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES): Provide
>	default #definition here, if tm-*.h file doesn't have one.
>	(symbol_init_mangled_name): If the above is #defined, strip off
>	the stdcall arg size, if present, from linker symbol names before
>	trying to demangle them.
>
>Index: gdb/symtab.c
>===================================================================
>RCS file: /cvs/src/src/gdb/symtab.c,v
>retrieving revision 1.59
>diff -c -r1.59 symtab.c
>*** gdb/symtab.c	2002/03/27 23:10:23	1.59
>--- gdb/symtab.c	2002/03/27 23:19:07
>***************
>*** 353,358 ****
>--- 353,362 ----
>  \f
>  /* Initialize a symbol's mangled name.  */
>  
>+ #ifndef LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES
>+ #define LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES (0)
>+ #endif
>+ 
>  /* Try to initialize the demangled name for a symbol, based on the
>     language of that symbol.  If the language is set to language_auto,
>     it will attempt to find any demangling algorithm that works and
>***************
>*** 369,381 ****
>    char *mangled = gsymbol->name;
>    char *demangled = NULL;
>  
>    if (gsymbol->language == language_unknown)
>      gsymbol->language = language_auto;
>    if (gsymbol->language == language_cplus
>        || gsymbol->language == language_auto)
>      {
>        demangled =
>!         cplus_demangle (gsymbol->name, DMGL_PARAMS | DMGL_ANSI);
>        if (demangled != NULL)
>          {
>            gsymbol->language = language_cplus;
>--- 373,418 ----
>    char *mangled = gsymbol->name;
>    char *demangled = NULL;
>  
>+   /* On Windows, some functions use the `stdcall' calling convention,
>+      in which the callee is expected to pop the arguments off the
>+      stack.  Normally, the caller takes care of this, because only the
>+      caller knows how many arguments it really passed.  To avoid
>+      confusion, the linker symbols for `stdcall' functions have names
>+      with a suffix "@N" attached to them, where "N" is the number of
>+      bytes they'll pop.  That way, if a caller thinks some `stdcall'
>+      function `foo' expects M argument bytes, but the definition of
>+      `foo' expects N argument bytes, N != M, then the call will be a
>+      reference to `foo@M', but the definition will have a linker
>+      symbol `foo@N', and you'll get a link-time `symbol not found'
>+      error, instead of a crash at run-time.
>+ 
>+      (Note how this fails to address calls through function pointers,
>+      since the byte count isn't part of the function pointer's type.
>+      Go, Microsoft!)
>+ 
>+      Whatever.  But our demangler doesn't like that '@N' suffix, so we
>+      need to strip it off.  */
>+   if (LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES)
>+     {
>+       char *arg_byte_suffix = strchr (mangled, '@');
>+       if (arg_byte_suffix)
>+         {
>+           int prefix_len = arg_byte_suffix - mangled;
>+           char *mangled_sans_suffix = alloca (prefix_len + 1);
>+           memcpy (mangled_sans_suffix, mangled, prefix_len);
>+           mangled_sans_suffix[prefix_len] = '\0';
>+ 
>+           mangled = mangled_sans_suffix;
>+         }
>+     }
>+ 
>    if (gsymbol->language == language_unknown)
>      gsymbol->language = language_auto;
>    if (gsymbol->language == language_cplus
>        || gsymbol->language == language_auto)
>      {
>        demangled =
>!         cplus_demangle (mangled, DMGL_PARAMS | DMGL_ANSI);
>        if (demangled != NULL)
>          {
>            gsymbol->language = language_cplus;
>***************
>*** 391,397 ****
>    if (gsymbol->language == language_java)
>      {
>        demangled =
>!         cplus_demangle (gsymbol->name,
>                          DMGL_PARAMS | DMGL_ANSI | DMGL_JAVA);
>        if (demangled != NULL)
>          {
>--- 428,434 ----
>    if (gsymbol->language == language_java)
>      {
>        demangled =
>!         cplus_demangle (mangled,
>                          DMGL_PARAMS | DMGL_ANSI | DMGL_JAVA);
>        if (demangled != NULL)
>          {
>Index: gdb/symtab.h
>===================================================================
>RCS file: /cvs/src/src/gdb/symtab.h,v
>retrieving revision 1.29
>diff -c -r1.29 symtab.h
>*** gdb/symtab.h	2002/03/27 23:10:24	1.29
>--- gdb/symtab.h	2002/03/27 23:19:08
>***************
>*** 159,170 ****
>        }									\
>    } while (0)
>  
>  #define SYMBOL_INIT_DEMANGLED_NAME(symbol,obstack) \
>    (symbol_init_demangled_name (&symbol->ginfo, (obstack)))
>  extern void symbol_init_demangled_name (struct general_symbol_info *symbol,
>                                          struct obstack *obstack);
>  
>-   
>  /* Macro that returns the demangled name for a symbol based on the language
>     for that symbol.  If no demangled name exists, returns NULL. */
>  
>--- 159,171 ----
>        }									\
>    } while (0)
>  
>+ 
>  #define SYMBOL_INIT_DEMANGLED_NAME(symbol,obstack) \
>    (symbol_init_demangled_name (&symbol->ginfo, (obstack)))
>  extern void symbol_init_demangled_name (struct general_symbol_info *symbol,
>                                          struct obstack *obstack);
>+ 
>  
>  /* Macro that returns the demangled name for a symbol based on the language
>     for that symbol.  If no demangled name exists, returns NULL. */
>  
>Index: gdb/config/i386/tm-cygwin.h
>===================================================================
>RCS file: /cvs/src/src/gdb/config/i386/tm-cygwin.h,v
>retrieving revision 1.11
>diff -c -r1.11 tm-cygwin.h
>*** gdb/config/i386/tm-cygwin.h	2001/11/27 05:15:58	1.11
>--- gdb/config/i386/tm-cygwin.h	2002/03/27 23:19:12
>***************
>*** 47,49 ****
>--- 47,51 ----
>  char *child_solib_loaded_library_pathname(int);
>  void child_clear_solibs (void);
>  void dll_symbol_command (char *, int);
>+ 
>+ #define LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES (1)

Re: RFA: strip stdcall suffixes under Cygwin

[Daniel Jacobowitz]

On Wed, Mar 27, 2002 at 06:35:25PM -0500, Jim Blandy wrote:
> 
> Chris, I think I need your approval for this.
> 
> 2002-03-27  Jim Blandy  <jimb@redhat.com>
> 
> 	* config/i386/tm-cygwin.h: #define
> 	LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES.
> 	* symtab.c (LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES): Provide
> 	default #definition here, if tm-*.h file doesn't have one.
> 	(symbol_init_mangled_name): If the above is #defined, strip off
> 	the stdcall arg size, if present, from linker symbol names before
> 	trying to demangle them.


> +   if (LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES)
> +     {
> +       char *arg_byte_suffix = strchr (mangled, '@');
> +       if (arg_byte_suffix)
> +         {
> +           int prefix_len = arg_byte_suffix - mangled;
> +           char *mangled_sans_suffix = alloca (prefix_len + 1);
> +           memcpy (mangled_sans_suffix, mangled, prefix_len);
> +           mangled_sans_suffix[prefix_len] = '\0';
> + 
> +           mangled = mangled_sans_suffix;
> +         }
> +     }
> + 

Perhaps verify that you are stripping off a number?

(ELF uses @ for representing symbol versions also.)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: strip stdcall suffixes under Cygwin

[Andrew Cagney]

> 2002-03-27  Jim Blandy  <jimb@redhat.com>
> 
> * config/i386/tm-cygwin.h: #define
> 	LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES.
> 	* symtab.c (LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES): Provide
> 	default #definition here, if tm-*.h file doesn't have one.
> 	(symbol_init_mangled_name): If the above is #defined, strip off
> 	the stdcall arg size, if present, from linker symbol names before
> 	trying to demangle them.
> 

Er, this is a new macro.  It should be a new method in the architecture 
vector.

enjoy,
Andrew

Re: RFA: strip stdcall suffixes under Cygwin

[Andrew Cagney]

> 2002-03-27  Jim Blandy  <jimb@redhat.com>
> 
> * config/i386/tm-cygwin.h: #define
>     LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES.
>     * symtab.c (LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES): Provide
>     default #definition here, if tm-*.h file doesn't have one.
>     (symbol_init_mangled_name): If the above is #defined, strip off
>     the stdcall arg size, if present, from linker symbol names before
>     trying to demangle them.
> 
> 
> Er, this is a new macro.  It should be a new method in the architecture vector.

Hmm (yes, I know, it's bad form to follow up your own e-mail), is this 
an attribute of the object file's symbol information and hence can be 
set by examining that info?  If that is true there is no need to 
multi-arch it.

enjoy,
Andrew

Re: RFA: strip stdcall suffixes under cygwin

[Christopher Faylor]

On Wed, Mar 27, 2002 at 08:57:28PM -0500, Andrew Cagney wrote:
>>2002-03-27  Jim Blandy  <jimb@redhat.com>
>>
>>* config/i386/tm-cygwin.h: #define
>>    LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES.
>>    * symtab.c (LINKER_SYMBOLS_HAVE_WIN32_STDCALL_ARG_SIZES): Provide
>>    default #definition here, if tm-*.h file doesn't have one.
>>    (symbol_init_mangled_name): If the above is #defined, strip off
>>    the stdcall arg size, if present, from linker symbol names before
>>    trying to demangle them.
>>
>>Er, this is a new macro.  It should be a new method in the architecture
>>vector.
>
>Hmm (yes, I know, it's bad form to follow up your own e-mail), is this
>an attribute of the object file's symbol information and hence can be
>set by examining that info?  If that is true there is no need to
>multi-arch it.

I'm not sure that I entirely understand the question but what this patch
is dealing with is the fact that on Windows function symbols sometimes
have a @n attached to them.  'n' is, as far as I know, never anything
other than a number.  The only time that a function looks like this is
when it is defined with the stdcall (and possibly fastcall) attribute.

So, the information could be derived at configure time, at least.  It's
purely a windows-specific thing though.  I don't think that there is any
other identifying information in the object file that would mark this as
a stdcall other than the addition of a '@' to the function name.

FWIW, this fixes a long standing problem in cygwin gdb where sometimes
functions are mysteriously inaccessible until you list the file that
encloses them.

cgf

Re: RFA: strip stdcall suffixes under cygwin

[Andrew Cagney]

> Hmm (yes, I know, it's bad form to follow up your own e-mail), is this
>>an attribute of the object file's symbol information and hence can be
>>set by examining that info?  If that is true there is no need to
>>multi-arch it.
> 
> 
> I'm not sure that I entirely understand the question but what this patch
> is dealing with is the fact that on Windows function symbols sometimes
> have a @n attached to them.  'n' is, as far as I know, never anything
> other than a number.  The only time that a function looks like this is
> when it is defined with the stdcall (and possibly fastcall) attribute.

It is just that new macro that is a problem.  New target dependant 
macros/methods need to be configured at run time.

> So, the information could be derived at configure time, at least.  It's
> purely a windows-specific thing though.  I don't think that there is any
> other identifying information in the object file that would mark this as
> a stdcall other than the addition of a '@' to the function name.

Would the executable file's format (MS PE?) identify the executable as 
belonging to windows?

enjoy,
Andrew

Re: RFA: strip stdcall suffixes under cygwin

[Christopher Faylor]

On Wed, Mar 27, 2002 at 11:03:51PM -0500, Andrew Cagney wrote:
>>Hmm (yes, I know, it's bad form to follow up your own e-mail), is this
>>>an attribute of the object file's symbol information and hence can be
>>>set by examining that info?  If that is true there is no need to
>>>multi-arch it.
>>
>>
>>I'm not sure that I entirely understand the question but what this patch
>>is dealing with is the fact that on Windows function symbols sometimes
>>have a @n attached to them.  'n' is, as far as I know, never anything
>>other than a number.  The only time that a function looks like this is
>>when it is defined with the stdcall (and possibly fastcall) attribute.
>
>It is just that new macro that is a problem.  New target dependant 
>macros/methods need to be configured at run time.

Right.  I thought if I explained what it was doing, either I'd figure
out the answer as I was typing or you'd figure it out as you were
reading.  :-)

>>So, the information could be derived at configure time, at least.  It's
>>purely a windows-specific thing though.  I don't think that there is
>>any other identifying information in the object file that would mark
>>this as a stdcall other than the addition of a '@' to the function
>>name.
>
>Would the executable file's format (MS PE?) identify the executable as
>belonging to windows?

Yes, certainly.  Are you saying the macro could be a global which is
set by detecting if the executable type was PE?

cgf

Re: RFA: strip stdcall suffixes under cygwin

[Andrew Cagney]

> Would the executable file's format (MS PE?) identify the executable as
>>belonging to windows?
> 
> 
> Yes, certainly.  Are you saying the macro could be a global which is
> set by detecting if the executable type was PE?

I suspect that the debug reader could identify and retain this 
information locally (in a variable/flag).  It must already do this for 
symbol tables and the like.  I don't think the macro is needed.

enjoy,
Andrew

PS: See 
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&database=gdb&pr=169