Re: RFA: strip stdcall suffixes under cygwin

[Christopher Faylor <cgf@redhat.com>]

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