On Wednesday, 22 April 2015 at 01:46:57 UTC, 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.

This is still broken
https://issues.dlang.org/show_bug.cgi?id=14178

I'm actually recoding the name mangling for linux/osx right now because the current implementation cannot work correctly with compression/substitutions (see http://mentorembedded.github.io/cxx-abi/abi.html#mangling-compression)

This is really tricky since substitution doesn't work the same when mangling template parameters or arguments. I'm making progress but there's a lot of gotchas. Especially if you start mixing namespace nesting, template instantiation and STL mangling substitutions.

You can have a look at the incomplete tests I have :
https://raw.githubusercontent.com/gchatelet/dmd/new_cpp_mangle/test/compilable/cppmangle.d

For instance this one is already pretty hard to understand :
_ZNK6nested21NestedTemplatedStructIiE23templatedMemberFunctionINS_12NestedStructEEEPT_PPKS4_
You can check the result with http://demangler.com/

Getting this right is a prerequisite to C++/STL integration.

"Guillaume Chatelet"  wrote in message news:vrcvkydsexiwamulangy@forum.dlang.org...

> This is still broken
> https://issues.dlang.org/show_bug.cgi?id=14178

That's not the issue we're talking about.

> I'm actually recoding the name mangling for linux/osx right now because the current implementation cannot work correctly with compression/substitutions (see http://mentorembedded.github.io/cxx-abi/abi.html#mangling-compression)
>
> This is really tricky since substitution doesn't work the same when mangling template parameters or arguments. I'm making progress but there's a lot of gotchas. Especially if you start mixing namespace nesting, template instantiation and STL mangling substitutions.

Good!  Features have mostly just been patched in as people needed them. 

Michel Fortin <michel.fortin@michelf.ca> writes:
>
> 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*));

I found that exists as core.demangle.mangleC() does exactly that, just
added last fall.

Since the compile chain knows whether the target system prepends an underscore, I wonder if it can be bubbled up into some compiler trait or version that prevents writing versioned code based on system.  I think it would help gdc much as it has many targets, and many prepend underscore to symbols.  It would help with unittests like compilable/cppmangle.d that would have to be tailored for every OS. that uses gcc3 style C++ mangling.

"Daniel Murphy" <yebbliesnospam@gmail.com> writes:

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

Then for systems that add underscore prefix to compiler identifiers, dmd .mangleof for extern(C) identifiers needs to include '_' prefix. I'll try this locally on OS X and see what breaks.

It also means ldc merge-2.067, which just got C++ object symbols correct with https://github.com/ldc-developers/ldc/pull/889, also needs to include '_' prefix in .mangleof result for extern(C++).

There should be some helper to determine if compiler will add underscores.  Otherwise I can see some unittests getting ugly.

On 20 April 2015 at 18:33, Dan Olson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> $ nm showmangle.o | grep fun
>                  U _D10showmangle4dfunFiZv
>                  U __Z6cxxfuni
>                  U _cfun
>
> --
> Dan

Because of this, debugging in OSX is not as good as it could be (if you use DMD).  All debuggers I've seen remove the leading '_' from symbols before they begin demangling symbols.

On 2015-04-22 16:32:55 +0000, Dan Olson <zans.is.for.cans@yahoo.com> said:

> Since the compile chain knows whether the target system prepends an
> underscore, I wonder if it can be bubbled up into some compiler trait or
> version that prevents writing versioned code based on system.  I think
> it would help gdc much as it has many targets, and many prepend
> underscore to symbols.  It would help with unittests like
> compilable/cppmangle.d that would have to be tailored for every OS.
> that uses gcc3 style C++ mangling.

And you think it's safe to assume all symbols on OS X will always have an underscore as a prefix just because symbols for C and C++ stuff do? (Hint: some Objective-C symbols don't start with "_".)

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On 22 April 2015 at 19:59, Michel Fortin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2015-04-22 16:32:55 +0000, Dan Olson <zans.is.for.cans@yahoo.com> said:
>
>> Since the compile chain knows whether the target system prepends an underscore, I wonder if it can be bubbled up into some compiler trait or version that prevents writing versioned code based on system.  I think it would help gdc much as it has many targets, and many prepend underscore to symbols.  It would help with unittests like compilable/cppmangle.d that would have to be tailored for every OS. that uses gcc3 style C++ mangling.
>
>
> And you think it's safe to assume all symbols on OS X will always have an underscore as a prefix just because symbols for C and C++ stuff do? (Hint: some Objective-C symbols don't start with "_".)
>

I think I've argued this before about pragma(mangle) - it's dangerous to put any asserts in the testsuite surrounding this or to write any library wrappers around it.

(FYI - last time I checked GDC goes ahead and applied target-specific
mangling on-top of pragma(mangle).  So you can relax and assume
nothing about the target).

Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> writes:
>
> (FYI - last time I checked GDC goes ahead and applied target-specific
> mangling on-top of pragma(mangle).  So you can relax and assume
> nothing about the target).

So does LDC.

Actually, DMD does too on OS X, but only for extern(C) - attention to
func plughc.

pragma(mangle, "plughc")   extern (C) void plughc();
pragma(mangle, "plughd")   extern(D) void plughd();
pragma(mangle, "plughcxx") extern(C++) void plughcxx();

pragma(msg, plughc.mangleof);
pragma(msg, plughd.mangleof);
pragma(msg, plughcxx.mangleof);

$ dmd -c showmangle.d
plughc
plughd
plughcxx

$ nm showmangle.o | grep plugh
                 U _plughc
                 U plughcxx
                 U plughd

Maybe this all needs to be left in implementation defined land?

Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> writes:
>
> Because of this, debugging in OSX is not as good as it could be (if you use DMD).  All debuggers I've seen remove the leading '_' from symbols before they begin demangling symbols.

And I noticed __cxa_demangle() is defined that way. Target specific prefix must be removed for it to work.

I'd like to get debugging working better on OS X. I saw posts where you improved GDB for D. I am going to try it out. Even though OS X has switched to lldb, gdb is what I know, and what Emacs knows too. Working on OS X debugging may help with understanding how D should deal with target specific underscores.

On 23 April 2015 at 19:15, Dan Olson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> writes:
>>
>> (FYI - last time I checked GDC goes ahead and applied target-specific
>> mangling on-top of pragma(mangle).  So you can relax and assume
>> nothing about the target).
>
> So does LDC.
>
> Actually, DMD does too on OS X, but only for extern(C) - attention to
> func plughc.
>
> pragma(mangle, "plughc")   extern (C) void plughc();
> pragma(mangle, "plughd")   extern(D) void plughd();
> pragma(mangle, "plughcxx") extern(C++) void plughcxx();
>
> pragma(msg, plughc.mangleof);
> pragma(msg, plughd.mangleof);
> pragma(msg, plughcxx.mangleof);
>
> $ dmd -c showmangle.d
> plughc
> plughd
> plughcxx
>
> $ nm showmangle.o | grep plugh
>                  U _plughc
>                  U plughcxx
>                  U plughd
>
> Maybe this all needs to be left in implementation defined land?

There should *always* be a prefix there. ;-)

A 'nice to know' which is specific to GDC.  If you prefix pragma(mangle) names with "*" then it will not apply target-dependent prefixes.

Regards
Iain