On Tuesday, 28 May 2013 at 13:06:01 UTC, Martin Nowak wrote:
> On 05/27/2013 06:18 PM, David Nadlinger wrote:
>> non-negligible code bloat
>
> I wouldn't really call this code bloat, as it only affects your object files, the linker and the runtime linker.

And unstripped executables.

David

On Tuesday, 28 May 2013 at 12:56:15 UTC, Martin Nowak wrote:
> On 05/27/2013 08:22 PM, deadalnix wrote:
>>
>> The way template are mangled in super redundant. This can probably be
>> fixed easily, but this is a breakage.
>
> How would you mangle them instead?

templateSymbolKKKtepplateArguments

Where KKK is anything, really, as long as it is unambiguous.

On 5/28/13 8:57 AM, Martin Nowak wrote:
> On 05/27/2013 10:34 PM, Peter Alexander wrote:
>>
>> Surely a better solution would be to use a lossless compression?
>
> Yeah, I would hate to loose the ability to demangle a symbol.

Well we'd need a scheme that compresses to text, e.g. binary compression followed by base64?

Andrei

On Mon, 27 May 2013 14:22:40 -0400, deadalnix <deadalnix@gmail.com> wrote:

> The way template are mangled in super redundant. This can probably be fixed easily, but this is a breakage.

Nothing is breakage before shared library support is ready.  And it's almost ready...

This should be addressed sooner rather than later.  And I think it's really important.

-Steve

On Tuesday, 28 May 2013 at 19:01:00 UTC, Steven Schveighoffer wrote:
> Nothing is breakage before shared library support is ready.  And it's almost ready...

This comment makes me slightly nervous, as I think even then, we shouldn't be too quick to commit to ABI stability. Quite on the contrary, we need to make sure to aggressively tell users that they can't expect two pieces D code that were not compiled with the exact same compiler version to interoperate.

One of the reasons is that we keep breaking ABI compatibility in Phobos with just about every single release.

And the more important and fundamental one is that we don't actually have a well-defined ABI right now (i.e. that is actually documented in the spec), which would also need to be actually implementable by all of DMD, GDC and LDC. Not to mention the many quirks and bugs in the current implementation.

David

On Tue, 28 May 2013 17:13:59 -0400, David Nadlinger <see@klickverbot.at> wrote:

> On Tuesday, 28 May 2013 at 19:01:00 UTC, Steven Schveighoffer wrote:
>> Nothing is breakage before shared library support is ready.  And it's almost ready...
>
> This comment makes me slightly nervous, as I think even then, we shouldn't be too quick to commit to ABI stability. Quite on the contrary, we need to make sure to aggressively tell users that they can't expect two pieces D code that were not compiled with the exact same compiler version to interoperate.

Like it or not, dynamic library support means we need to pay more attention to ABI breakage.  People will complain about what largely is not really a problem (since code is statically compiled, you essentially build it every time anyway).

This isn't to say we can't put a big fat warning, but we will have to resist a new onslaught of "please don't release this compiler, it breaks all my customer's installations!" complaints.

> One of the reasons is that we keep breaking ABI compatibility in Phobos with just about every single release.

Again, this isn't a huge issue when everything is static.  When things are dynamic, you can't even be sure what the target system HAS on it, stability is really important.

> And the more important and fundamental one is that we don't actually have a well-defined ABI right now (i.e. that is actually documented in the spec), which would also need to be actually implementable by all of DMD, GDC and LDC. Not to mention the many quirks and bugs in the current implementation.

That has to be resolved too, but it may not be as interesting to someone who wants to fix mangling.  We can accept both fixes simultaneously :)

-Steve

Am Tue, 28 May 2013 18:26:08 -0400
schrieb "Steven Schveighoffer" <schveiguy@yahoo.com>:

> On Tue, 28 May 2013 17:13:59 -0400, David Nadlinger <see@klickverbot.at> wrote:
> 
> > On Tuesday, 28 May 2013 at 19:01:00 UTC, Steven Schveighoffer wrote:
> >> Nothing is breakage before shared library support is ready.  And it's almost ready...
> >
> > This comment makes me slightly nervous, as I think even then, we shouldn't be too quick to commit to ABI stability. Quite on the contrary, we need to make sure to aggressively tell users that they can't expect two pieces D code that were not compiled with the exact same compiler version to interoperate.
> 
> Like it or not, dynamic library support means we need to pay more attention to ABI breakage.  People will complain about what largely is not really a problem (since code is statically compiled, you essentially build it every time anyway).

We only have to do the library versioning right. If we increase the major version with every release we can break the ABI as much as we want. Older applications the will always use the old shared libraries, newer application the new ones. This means you'll have 3-4 copies of phobos/druntime on your system, but I don't think that is an issue.

I agree with David that stabilizing the ABI is not a good idea right now. We don't have a standard ABI, toString/toHash might need to be removed which will break everything, we have some modules in phobos that should be replaced ASAP (std.stream, std.xml)...

On 05/29/2013 09:09 AM, Johannes Pfau wrote:
> We only have to do the library versioning right.

The phobos make file currently builds libphobos2.so.0.63.0 and uses libphobos2.so.0.63 as the soname. So an app linked with the shared phobos will be using libphobos2.so.0.63, the .63 comes from the dmd/phobos version and can be dropped when the ABI is stable.

-- 
Mike Wey

On 5/27/2013 11:14 AM, Peter Alexander wrote:
> The symbols typically contain a lot of repeated sub strings. Perhaps there is a
> better mangling scheme that encodes it with some kind of prefix tree?

Rather than a new scheme, a simple and effective approach is to compress using lzw. Lzw is nicely reversible, too, though the symbols will look like tty noise in the linker maps and the debugger.

One approach is to lzw them only if they exceed a certain length, and to leave a prefix that makes some sense to the user, like the function name.

On Fri, Dec 06, 2013 at 03:26:53PM -0800, Walter Bright wrote:
> On 5/27/2013 11:14 AM, Peter Alexander wrote:
> >The symbols typically contain a lot of repeated sub strings. Perhaps there is a better mangling scheme that encodes it with some kind of prefix tree?
> 
> Rather than a new scheme, a simple and effective approach is to compress using lzw. Lzw is nicely reversible, too, though the symbols will look like tty noise in the linker maps and the debugger.
> 
> One approach is to lzw them only if they exceed a certain length, and to leave a prefix that makes some sense to the user, like the function name.

Looking like noise shouldn't be a problem, as long as ddemangle is updated to be able to interpret them. I doubt very many people can demangle D symbols in their head anyway; most would use ddemangle.

Leaving the function name in is a good compromise, though not strictly necessary if ddemangle can interpret the lzw noise.

On that note, core.demangle seriously needs to be able to demangle *all* mangled symbols (like module ctors, typeinfos, vtables, etc.), not just function symbols. Running `nm program | ddemangle` still leaves about half the symbols mangled, which is annoying when you're trying to figure out what those symbols are referring to.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need before which you can't deliver after.