From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23952 invoked by alias); 28 Mar 2002 04:09:00 -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 23943 invoked from network); 28 Mar 2002 04:08:59 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 28 Mar 2002 04:08:59 -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 g2S48wN32408 for ; Wed, 27 Mar 2002 23:08:58 -0500 Received: (from cgf@localhost) by cgf.cipe.redhat.com (8.11.6/8.8.7) id g2S495m05885 for gdb-patches@sources.redhat.com; Wed, 27 Mar 2002 23:09:05 -0500 Date: Wed, 27 Mar 2002 20:09:00 -0000 From: Christopher Faylor To: gdb-patches@sources.redhat.com Subject: Re: RFA: strip stdcall suffixes under cygwin Message-ID: <20020328040905.GA5852@redhat.com> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20020327233525.1164E5EA11@zwingli.cygnus.com> <3CA25A74.6050807@cygnus.com> <3CA27888.2070407@cygnus.com> <20020328034207.GI1617@redhat.com> <3CA29627.5040900@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CA29627.5040900@cygnus.com> User-Agent: Mutt/1.3.23.1i X-SW-Source: 2002-03/txt/msg00572.txt.bz2 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