View mode: basic / threaded / horizontal-split · Log in · Help
July 22, 2012
Re: Optional name mangling
On Jul 22, 2012, at 6:12 AM, "Stuart" <stugol@gmx.com> wrote:

> On Sunday, 22 July 2012 at 07:01:50 UTC, Walter Bright wrote:
>> This is a very old issue. To be compatible with the output of the Microsoft C compiler, the Windows calling convention is:
>> 
>>   _name@nn
>> 
>> but somehow Microsoft left off the _ and @nn in the DLLs. Hence, part of the whole reason for the import libraries is then to provide a mapping of _name@nn => name.
>> 
>> I have no idea who made this decision and why, but we're stuck with it.
> 
> Okay, but if you had a keyword - say, "extern(rawC)" - that did no mangling whatsoever, then I could run implib without manually editing every single damn line in every Microsoft .def file by hand!!! Surely that's a good idea?
> 
> I don't know why implib is ignoring the /s switch, but it is. My .lib file doesn't have underscores, and there doesn't seem to be much I can do about it. Do I need a different version of implib or something? Shouldn't the /s switch add underscores to everything?

I think there's definitely some use in being able to specify a symbol name as a string, both for aliasing external symbols and overriding name mangling of internal symbols.
July 23, 2012
Re: Optional name mangling
On 2012-07-22 15:12, Stuart wrote:

> I don't know why implib is ignoring the /s switch, but it is. My .lib
> file doesn't have underscores, and there doesn't seem to be much I can
> do about it. Do I need a different version of implib or something?
> Shouldn't the /s switch add underscores to everything?

I used it a couple of weeks ago and it worked.

-- 
/Jacob Carlborg
July 23, 2012
Re: Optional name mangling
On 7/22/2012 6:12 AM, Stuart wrote:
> Okay, but if you had a keyword - say, "extern(rawC)" - that did no mangling
> whatsoever, then I could run implib without manually editing every single damn
> line in every Microsoft .def file by hand!!! Surely that's a good idea?

I agree, it's a pain, and a pointless one at that.

> I don't know why implib is ignoring the /s switch, but it is. My .lib file
> doesn't have underscores, and there doesn't seem to be much I can do about it.
> Do I need a different version of implib or something? Shouldn't the /s switch
> add underscores to everything?

There's no magical way for implib to figure out what the nn in @nn must be.
July 23, 2012
Re: Optional name mangling
On Monday, 23 July 2012 at 06:28:56 UTC, Jacob Carlborg wrote:
> On 2012-07-22 15:12, Stuart wrote:
>
>> I don't know why implib is ignoring the /s switch, but it is.
>
> I used it a couple of weeks ago and it worked.

Oh, well, I guess that makes it alright, huh? I guess I must just 
be an idiot, or hallucinating, yeah?

Alternatively, you could take my word for it when I say it ain't 
working, and offer some kind of constructive advice.
July 23, 2012
Re: Optional name mangling
On Monday, 23 July 2012 at 06:44:22 UTC, Walter Bright wrote:
> On 7/22/2012 6:12 AM, Stuart wrote:
>> Okay, but if you had a keyword - say, "extern(rawC)" - that 
>> did no mangling
>> whatsoever, then I could run implib without manually editing 
>> every single damn
>> line in every Microsoft .def file by hand!!! Surely that's a 
>> good idea?
>
> I agree, it's a pain, and a pointless one at that.
>
>> I don't know why implib is ignoring the /s switch, but it is. 
>> My .lib file
>> doesn't have underscores, and there doesn't seem to be much I 
>> can do about it.
>> Do I need a different version of implib or something? 
>> Shouldn't the /s switch
>> add underscores to everything?
>
> There's no magical way for implib to figure out what the nn in 
> @nn must be.

Granted, but IMPLIB IS NOT PREFIXING THE NAMES WITH AN 
UNDERSCORE, even when used with the /s switch. Hello? Houston? Am 
I getting through?

In any case, adding support for importing unmangled function 
names in D would help in these cases; and also allow us to import 
unmangled functions that were exported from C using the "extern 
C" instruction in C++.

Correct me if I'm wrong, but isn't it only C++ that does 
mangling? As I recall, straight C doesn't support overloading and 
doesn't mangle names. Therefore, I reckon your "extern (C)" 
instruction ought instead to be written "extern (C++)", and a new 
"extern (C)" should be introduced that does no name mangling. 
Alternatively, I may be wrong, but even so, a non-mangling 
keyword would be helpful. And surely it wouldn't be difficult to 
implement?
July 23, 2012
Re: Optional name mangling
"Stuart" <stugol@gmx.com> wrote in message 
news:hcrszoaeyauztrlpifgu@forum.dlang.org...
> Correct me if I'm wrong, but isn't it only C++ that does mangling?

You're wrong.
July 23, 2012
Re: Optional name mangling
On Monday, 23 July 2012 at 14:08:39 UTC, Daniel Murphy wrote:
> "Stuart" <stugol@gmx.com> wrote in message
> news:hcrszoaeyauztrlpifgu@forum.dlang.org...
>> Correct me if I'm wrong, but isn't it only C++ that does 
>> mangling?
>
> You're wrong.

Fair enough. But there are still times when we need a version of 
"export" that doesn't mangle.
July 23, 2012
Re: Optional name mangling
On Monday, 23 July 2012 at 17:25:43 UTC, Stuart wrote:
> Fair enough. But there are still times when we need a version 
> of "export" that doesn't mangle.

No. This is even impossible to do with some compiler backends. 
For example, LLVM on OS X automatically appends an underscore to 
the beginning of symbol names, because every C function has an 
»extra« underscore at the beginning there.

David
July 23, 2012
Re: Optional name mangling
On Monday, 23 July 2012 at 17:28:38 UTC, David Nadlinger wrote:
> On Monday, 23 July 2012 at 17:25:43 UTC, Stuart wrote:
>> Fair enough. But there are still times when we need a version 
>> of "export" that doesn't mangle.
>
> No. This is even impossible to do with some compiler backends. 
> For example, LLVM on OS X automatically appends an underscore 
> to the beginning of symbol names, because every C function has 
> an »extra« underscore at the beginning there.

I mean for importing. The functions in shlwapi.lib don't have 
underscores. We ought to have some kind of syntax for importing 
them without faffing about with .def files. Surely it must be 
possible?
July 23, 2012
Re: Optional name mangling
On Monday, 23 July 2012 at 20:57:37 UTC, Stuart wrote:
> On Monday, 23 July 2012 at 17:28:38 UTC, David Nadlinger wrote:
>> On Monday, 23 July 2012 at 17:25:43 UTC, Stuart wrote:
>>> Fair enough. But there are still times when we need a version 
>>> of "export" that doesn't mangle.
>>
>> No. This is even impossible to do with some compiler backends. 
>> For example, LLVM on OS X automatically appends an underscore 
>> to the beginning of symbol names, because every C function has 
>> an »extra« underscore at the beginning there.
>
> I mean for importing. The functions in shlwapi.lib don't have 
> underscores. We ought to have some kind of syntax for importing 
> them without faffing about with .def files. Surely it must be 
> possible?

Hi Stuart.

If you have the Windows SDK you can run

coffimplib "C:\Program Files (x86)\Microsoft 
SDKs\Windows\v7.0A\Lib\shlwapi.lib" 
C:\D\dmd2\windows\lib\shlwapi.lib

We could run coffimplib on *.lib from the Windows SDK and include 
the resulting OMF libraries on the dmd.zip package. I don't know 
if it is 'legal'.
1 2 3 4
Top | Discussion index | About this forum | D home