On Saturday, 4 May 2019 at 14:05:00 UTC, Jack Applegame wrote:
> pragma(LDC_no_typeinfo)
> [...]
> Nothing changes.

Thanks for noting, that's a bug, tackled in https://github.com/ldc-developers/ldc/pull/3068.

On Saturday, 4 May 2019 at 16:49:48 UTC, kinke wrote:
> Thanks for noting, that's a bug, tackled in https://github.com/ldc-developers/ldc/pull/3068.
Thanks for fixing.
And why `-data-sections` flag also doesn't change anything?

On Saturday, 4 May 2019 at 18:37:40 UTC, Jack Applegame wrote:
> And why `-data-sections` flag also doesn't change anything?

This seems to be the perfectly corresponding C++ question (string literals placed shared readonly section) with a nice answer:
https://stackoverflow.com/questions/54996229/is-ffunction-sections-fdata-sections-and-gc-sections-not-working

LDC emits these strings as private constants in LLVM IR.

On Saturday, 4 May 2019 at 19:06:26 UTC, kinke wrote:
> On Saturday, 4 May 2019 at 18:37:40 UTC, Jack Applegame wrote:
>> And why `-data-sections` flag also doesn't change anything?
>
> This seems to be the perfectly corresponding C++ question (string literals placed shared readonly section) with a nice answer:
> https://stackoverflow.com/questions/54996229/is-ffunction-sections-fdata-sections-and-gc-sections-not-working
>
> LDC emits these strings as private constants in LLVM IR.

Thanks. Now I see.

On 5 May 2019, at 8:29, Jack Applegame via digitalmars-d-ldc wrote:
> On Saturday, 4 May 2019 at 19:06:26 UTC, kinke wrote:
>> This seems to be the perfectly corresponding C++ question (string literals placed shared readonly section) with a nice answer:
>> https://stackoverflow.com/questions/54996229/is-ffunction-sections-fdata-sections-and-gc-sections-not-working
>>
>> LDC emits these strings as private constants in LLVM IR.
>
> Thanks. Now I see.

Next question: How do we fix this?

It seems like GCC might handle this by default: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192

 —David

On Sunday, 5 May 2019 at 15:40:58 UTC, David Nadlinger wrote:

> Next question: How do we fix this?
>
> It seems like GCC might handle this by default: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
>
>  —David

Iain fixed a similar issue a few years ago.  I'm not sure if it's related or not: See the last comment here:  https://issues.dlang.org/show_bug.cgi?id=14758

Mike

On 5 May 2019, at 21:57, Mike Franklin via digitalmars-d-ldc wrote:
> Iain fixed a similar issue a few years ago.  I'm not sure if it's related or not: See the last comment here:  https://issues.dlang.org/show_bug.cgi?id=14758

I haven't looked at that report in detail, but sure, making the string literals named symbols is a possible workaround.

It would just be nice to avoid having to do that manually and instead have LLVM emit them in whatever way appropriate to get both constant merging (where applicable) and linker garbage collection.

 — David

On Saturday, 4 May 2019 at 19:06:26 UTC, kinke wrote:
> On Saturday, 4 May 2019 at 18:37:40 UTC, Jack Applegame wrote:
>> And why `-data-sections` flag also doesn't change anything?
>
> This seems to be the perfectly corresponding C++ question (string literals placed shared readonly section) with a nice answer:
> https://stackoverflow.com/questions/54996229/is-ffunction-sections-fdata-sections-and-gc-sections-not-working
>
> LDC emits these strings as private constants in LLVM IR.

How difficult to fix it? I could donate money for the work.

On Wednesday, 8 May 2019 at 09:18:23 UTC, Jack Applegame wrote:
> How difficult to fix it? I could donate money for the work.

Should be straight-forward, but I fully agree with David and would rather have LLVM provide that functionality - maybe it already does and we just don't know about it yet. ;)

On Wednesday, 8 May 2019 at 15:16:26 UTC, kinke wrote:
> On Wednesday, 8 May 2019 at 09:18:23 UTC, Jack Applegame wrote:
>> How difficult to fix it? I could donate money for the work.
>
> Should be straight-forward, but I fully agree with David and would rather have LLVM provide that functionality - maybe it already does and we just don't know about it yet. ;)

I tried to use `lld` instead of `arm-none-eabi-ld` and got some interesting results.
`lld` successfully removed unused string constants.

I found that there is special SFH_MERGE flag. The linker should remove unused constants and merge duplicates in sections marked with this flag. But it seems that the GNU linker ignores it.