Re: RFA: strip stdcall suffixes under cygwin

[Christopher Faylor <cgf@redhat.com>]

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