Name Mangling & its representation of D types

Mathias LANG geod24 at gmail.com
Wed Aug 4 02:01:54 UTC 2021


On Tuesday, 3 August 2021 at 20:29:10 UTC, NonNull wrote:
> On Tuesday, 3 August 2021 at 17:01:38 UTC, Mike Parker wrote:
>> On Tuesday, 3 August 2021 at 16:43:52 UTC, NonNull wrote:
>>> how does it work for recursive types like a struct containing 
>>> a pointer to a struct of the same type
>>
>> A struct `S` with a member of type `S*` is still just a struct 
>> `S`. The pointer doesn't change anything about the type.
>
> Aha, so it just uses the name S, not an algebraic 
> representation of the structure of S.

Yes, because D is a nominal type system, using the FQN of the 
symbol is enough.

Mangled names start with `_D` and then contain the encoding of 
the symbol being mangled (can be a variable, a function, etc...).

To avoid an explosion in the symbol length we have back reference 
(which the blog mentions IIRC). Not only are parameter types 
encoded, but so are function attributes (`@safe` and co), with 
the notable exception of inferred `scope`, to allow people to 
link `-dip1000` code with non-DIP1000 code.

`core.demangle` provides a programmatic way to demangle a symbol 
to its code representation. `ddemangle`, packed with DMD, allow 
to do it via the CLI (similar to `c++filt`). Newer binutils have 
support for D as well, so `nm --demangle=dlang` works (note that 
some older binutils support this, but don't support backref).

Mangling is altered by `extern(LANG)` (where LANG is one of `C`, 
`C++`, `Objective-C`, `System`, `D`), or `pragma(mangle)`.


More information about the Digitalmars-d-learn mailing list