reduce mangled name sizes via link-time symbol renaming

[Johannes Pfau]

Am Thu, 25 Jan 2018 14:24:12 -0800
schrieb Timothee Cour <thelastmammoth at gmail.com>:

> could a solution like proposed below be adapted to automatically
> reduce size of long symbol names?
> 
> It allows final object files to be smaller; eg see the problem this
> causes:
> 
> * String Switch Lowering:
> http://forum.dlang.org/thread/p4d777$1vij$1@digitalmars.com
> caution: NSFW! contains huge mangled symbol name!
> * http://lists.llvm.org/pipermail/lldb-dev/2018-January/013180.html
> "[lldb-dev] Huge mangled names are causing long delays when loading
> symbol table symbols")
> 
> 
> ```
> main.d:
> void foo_test1(){ }
> void main(){ foo_test1(); }
> 
> dmd -c libmain.a
> 
> ld -r libmain.a -o libmain2.a -alias _D4main9foo_test1FZv _foobar
> -unexported_symbol _D4main9foo_test1FZv
> # or : via `-alias_list filename`
> 
> #NOTE: dummy.d only needed because somehow dmd needs at least one
> object file or source file, a static library is somehow not enough
> (dmd bug?)
> 
> dmd -of=main2 libmain2.a dummy.d
> 
> nm main2 | grep _foobar # ok
> 
> ./main2 # ok
> ```
> 
> NOTE: to automate this process it could find all symbol names >
> threshold and apply a mapping form long mangled names to short aliases
> (eg: object_file_name + incremented_counter), that file with all the
> mappings can be supplied for a demangler (eg for lldb/gdb debugging
> etc)

What is the benefit of using link-time renaming (a linker specific
feature) instead of directly renaming the symbol in the compiler? We
could be quite radical and hash all symbols > a certain threshold. As
long as we have a hash function with strong enough collision resistance
there shouldn't be any problem.

AFAICS we only need the mapping hashed_name ==> full name for
debugging. So maybe we can simply stuff the full, mangled name somehow
into dwarf debug information? We can even keep dwarf debug information
in external files and support for this is just being added to GCCs
libbacktrace, so even stack traces could work fine.

-- Johannes