Thread overview | |||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
April 20, 2015 C++/C mangleof inconsistency for OS X | ||||
---|---|---|---|---|
| ||||
An observation on OSX w/ 2.067: mangleof for C++ (and D) names produces the actual object file symbol while mangleof for C names strips a leading underscore. Is this intended? If so what is rationale? Demo $ cat >showmangle.d <<XYZZY void dfun(int); extern(C++) void cxxfun(int); extern (C) void cfun(int); pragma(msg, dfun.mangleof); pragma(msg, cxxfun.mangleof); pragma(msg, cfun.mangleof); void main() { dfun(1); cxxfun(1); cfun(1); } XYZZY $ dmd -c showmangle.d _D10showmangle4dfunFiZv __Z6cxxfuni cfun $ nm showmangle.o | grep fun U _D10showmangle4dfunFiZv U __Z6cxxfuni U _cfun -- Dan |
April 21, 2015 Re: C++/C mangleof inconsistency for OS X | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dan Olson | On 2015-04-20 18:33, Dan Olson wrote: > An observation on OSX w/ 2.067: mangleof for C++ (and D) names produces > the actual object file symbol while mangleof for C names strips a > leading underscore. > > Is this intended? If so what is rationale? I don't think it's intentional. The point of "mangleof" is to evaluate to the actual mangled name, as it appears in the object file. -- /Jacob Carlborg |
April 21, 2015 Re: C++/C mangleof inconsistency for OS X | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | Jacob Carlborg <doob@me.com> writes: > On 2015-04-20 18:33, Dan Olson wrote: >> An observation on OSX w/ 2.067: mangleof for C++ (and D) names produces the actual object file symbol while mangleof for C names strips a leading underscore. >> >> Is this intended? If so what is rationale? > > I don't think it's intentional. The point of "mangleof" is to evaluate to the actual mangled name, as it appears in the object file. Thanks Jacob. In that case, mangleof for extern(C) names on OS X and other systems that add a leading underscore should include the underscore. extern(C) int x; version(linux) pragma(msg, foo.mangleof); // "x" version(OSX) pragma(msg, foo.mangleof); // "_x" I'm trying to understand because ldc is different than dmd, and it is related to proper debugging on systems with leading underscores. pragma(mangle, name) is wrapped up in this too. This needs to be right to help D expand to other systems. -- Dan |
April 21, 2015 Re: C++/C mangleof inconsistency for OS X | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dan Olson | Dan Olson <zans.is.for.cans@yahoo.com> writes:
> Jacob Carlborg <doob@me.com> writes:
>
>> On 2015-04-20 18:33, Dan Olson wrote:
>>> An observation on OSX w/ 2.067: mangleof for C++ (and D) names produces the actual object file symbol while mangleof for C names strips a leading underscore.
>>>
>>> Is this intended? If so what is rationale?
>>
>> I don't think it's intentional. The point of "mangleof" is to evaluate to the actual mangled name, as it appears in the object file.
>
> Thanks Jacob.
>
> In that case, mangleof for extern(C) names on OS X and other systems that add a leading underscore should include the underscore.
>
> extern(C) int x;
> version(linux) pragma(msg, foo.mangleof); // "x"
> version(OSX) pragma(msg, foo.mangleof); // "_x"
>
> I'm trying to understand because ldc is different than dmd, and it is related to proper debugging on systems with leading underscores. pragma(mangle, name) is wrapped up in this too. This needs to be right to help D expand to other systems.
Hmmm, I can see another point of view where mangleof should produce the equivalent extern(C) symbol. My gut says this is the way it should work.
If I want to call a C function void debug(const char*) from a C library, I would do this because of D "debug" keyword:
pragma(mangle, "debug")
extern (C) void debug_c(const(char*));
Now I would think debug_c.mangleof -> "debug"
(and that is indeed what dmd produces even on OS X).
On systems which prepend an underscore, we want compiler to take care of this so code is portable, otherwise code must do this:
version (OSX)
pragma(mangle, "_debug") extern (C) void debug_c(const(char*));
else
pragma(mangle, "debug") extern (C) void debug_c(const(char*));
--
Dan
|
April 21, 2015 Re: C++/C mangleof inconsistency for OS X | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dan Olson | On 2015-04-21 19:01, Dan Olson wrote: > Hmmm, I can see another point of view where mangleof should produce the > equivalent extern(C) symbol. My gut says this is the way it should > work. That makes sense. > If I want to call a C function void debug(const char*) from a C library, > I would do this because of D "debug" keyword: > > pragma(mangle, "debug") > extern (C) void debug_c(const(char*)); > > Now I would think debug_c.mangleof -> "debug" > (and that is indeed what dmd produces even on OS X). Are there use cases where one would want to use some other mangling than C? I mean, D is a system programing language. > On systems which prepend an underscore, we want compiler to take care of > this so code is portable, otherwise code must do this: > > version (OSX) > pragma(mangle, "_debug") extern (C) void debug_c(const(char*)); > else > pragma(mangle, "debug") extern (C) void debug_c(const(char*)); These are all good points. -- /Jacob Carlborg |
April 21, 2015 Re: C++/C mangleof inconsistency for OS X | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dan Olson | On 2015-04-21 17:01:51 +0000, Dan Olson <zans.is.for.cans@yahoo.com> said: > Dan Olson <zans.is.for.cans@yahoo.com> writes: > >> Jacob Carlborg <doob@me.com> writes: >> >>> On 2015-04-20 18:33, Dan Olson wrote: >>>> An observation on OSX w/ 2.067: mangleof for C++ (and D) names produces >>>> the actual object file symbol while mangleof for C names strips a >>>> leading underscore. >>>> >>>> Is this intended? If so what is rationale? >>> >>> I don't think it's intentional. The point of "mangleof" is to evaluate >>> to the actual mangled name, as it appears in the object file. >> >> Thanks Jacob. >> >> In that case, mangleof for extern(C) names on OS X and other systems >> that add a leading underscore should include the underscore. >> >> extern(C) int x; >> version(linux) pragma(msg, foo.mangleof); // "x" >> version(OSX) pragma(msg, foo.mangleof); // "_x" >> >> I'm trying to understand because ldc is different than dmd, and it is >> related to proper debugging on systems with leading underscores. >> pragma(mangle, name) is wrapped up in this too. This needs to be right >> to help D expand to other systems. > > Hmmm, I can see another point of view where mangleof should produce the > equivalent extern(C) symbol. My gut says this is the way it should > work. > > If I want to call a C function void debug(const char*) from a C library, > I would do this because of D "debug" keyword: > > pragma(mangle, "debug") > extern (C) void debug_c(const(char*)); > > Now I would think debug_c.mangleof -> "debug" > (and that is indeed what dmd produces even on OS X). > > On systems which prepend an underscore, we want compiler to take care of > this so code is portable, otherwise code must do this: > > version (OSX) > pragma(mangle, "_debug") extern (C) void debug_c(const(char*)); > else > pragma(mangle, "debug") extern (C) void debug_c(const(char*)); I think if you specify the mangling most of the time it's because you don't want the compiler to do it for you. But you should consider doing this: string mangleC(string name) { version (OSX) return "_" ~ name; else return name; } pragma(mangle, mangleC("debug")) extern (C) void debug_c(const(char*)); -- Michel Fortin michel.fortin@michelf.ca http://michelf.ca |
April 21, 2015 Re: C++/C mangleof inconsistency for OS X | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On 2015-04-21 18:29:36 +0000, Jacob Carlborg <doob@me.com> said: > On 2015-04-21 19:01, Dan Olson wrote: > >> If I want to call a C function void debug(const char*) from a C library, >> I would do this because of D "debug" keyword: >> >> pragma(mangle, "debug") >> extern (C) void debug_c(const(char*)); >> >> Now I would think debug_c.mangleof -> "debug" >> (and that is indeed what dmd produces even on OS X). > > Are there use cases where one would want to use some other mangling than C? I mean, D is a system programing language. Apple does this in many of its own C headers. Lookup the definition of pthread_join for instance, you'll see the __DARWIN_ALIAS macro which when expanded under certain circumstances adds a suffix to the symbol name in a similar way to pragma(mangle) in D. This allows some fixes to only apply to code compiled with newer SDKs. (Also note that the underscore is explicitly put there by the macro.) -- Michel Fortin michel.fortin@michelf.ca http://michelf.ca |
April 22, 2015 Re: C++/C mangleof inconsistency for OS X | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dan Olson | "Dan Olson" wrote in message news:m28udmoj3v.fsf@comcast.net... > An observation on OSX w/ 2.067: mangleof for C++ (and D) names produces > the actual object file symbol while mangleof for C names strips a > leading underscore. > > Is this intended? If so what is rationale? Until fairly recently .mangleof was completely broken for eg extern(C++) mangling on windows. I'm not surprised there are still bugs there. Ideally .mangleof will give exactly the string that ends up in the object file. |
April 22, 2015 Re: C++/C mangleof inconsistency for OS X | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | On 2015-04-22 03:46, Daniel Murphy wrote: > Until fairly recently .mangleof was completely broken for eg extern(C++) > mangling on windows. I'm not surprised there are still bugs there. > Ideally .mangleof will give exactly the string that ends up in the > object file. And what about pragma(mangle), should that output the symbol name completely untouched? -- /Jacob Carlborg |
April 22, 2015 Re: C++/C mangleof inconsistency for OS X | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | "Jacob Carlborg" wrote in message news:mh7mka$19r9$1@digitalmars.com... > And what about pragma(mangle), should that output the symbol name completely untouched? Yes. |
Copyright © 1999-2021 by the D Language Foundation