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 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