This is the mail archive of the
mailing list for the binutils project.
Re: [patch] msvc demangling binutils
- From: Christopher Faylor <me at cgf dot cx>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: "Aaron W. LaFramboise" <aaron98wiridge9 at aaronwl dot com>,Eddy Pronk <epronk at muftor dot com>, binutils at sources dot redhat dot com
- Date: Tue, 20 Jul 2004 11:48:16 -0400
- Subject: Re: [patch] msvc demangling binutils
- References: <40D91FA5.email@example.com> <40F69616.firstname.lastname@example.org> <40F7020A.email@example.com> <40FD304F.firstname.lastname@example.org>
On Tue, Jul 20, 2004 at 03:46:39PM +0100, Nick Clifton wrote:
>>That doesn't really matter, though, because theres another way to do
>>this. Eric Pouech emailed me to let me know theres an apparently
>>undocumented function call in the standard msvcrt, which is definitely
>>considered to be part of the system, and present for all modern
>>i686-pc-mingw32 targets, that apparently does the same thing.
>>I haven't gotten around to messing with this, but when I do, I plan on
>>submitting a patch.
>OK - I will look forward to that, although please remember that if this
>feature is only going to be available on particular hosts you will need
>to make sure that the configure system is updated so that the code is
>only compiled in if the system call is going to be available.
Don't you really have to make this detectable at runtime? Otherwise,
you'll be producing binaries which may not work on some systems.
Also, the distinction between msvcrt and some other Microsoft-supplied
library doesn't make much sense to me. There are all sorts of different
versions of msvcrt, some are distributed after the fact. I think that
the use of UndecorateSymbolName should be allowed since it is distributed
as part of all modern Windows OS's. IMO, it should just be loaded via
dlopen or LoadLibrary to protect against old systems which do not have