This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: strip stdcall suffixes under cygwin
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