From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27265 invoked by alias); 28 Mar 2002 03:42:01 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 27242 invoked from network); 28 Mar 2002 03:42:00 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 28 Mar 2002 03:42:00 -0000 Received: from cgf.cipe.redhat.com (cgf.cipe.redhat.com [10.0.1.172]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id g2S3fxN27264 for ; Wed, 27 Mar 2002 22:41:59 -0500 Received: (from cgf@localhost) by cgf.cipe.redhat.com (8.11.6/8.8.7) id g2S3g7J05613 for gdb-patches@sources.redhat.com; Wed, 27 Mar 2002 22:42:07 -0500 Date: Wed, 27 Mar 2002 19:42:00 -0000 From: Christopher Faylor To: gdb-patches@sources.redhat.com Subject: Re: RFA: strip stdcall suffixes under cygwin Message-ID: <20020328034207.GI1617@redhat.com> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20020327233525.1164E5EA11@zwingli.cygnus.com> <3CA25A74.6050807@cygnus.com> <3CA27888.2070407@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CA27888.2070407@cygnus.com> User-Agent: Mutt/1.3.23.1i X-SW-Source: 2002-03/txt/msg00569.txt.bz2 On Wed, Mar 27, 2002 at 08:57:28PM -0500, Andrew Cagney wrote: >>2002-03-27 Jim Blandy >> >>* 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