On Fri, 02 Oct 2020 18:11:45 +0200, Jan Kratochvil wrote:
On Wed, 30 Sep 2020 15:58:51 +0200, Stephen John Smoogen wrote:
> On Wed, 30 Sep 2020 at 09:41, Jan Kratochvil <jan.kratochvil(a)redhat.com>
> > On Wed, 30 Sep 2020 14:50:39 +0200, Mark Wielaard wrote:
> > > = What I am NOT working on
> > [...]
> > > - Any other tool, project not mentioned above or other
> > > native toolchains like golang, rust, clang/llvm or ocaml.
> > > I expect those to simply keep producing DWARF4.
> > So because of a DWZ deficiency you want to keep DWARF-5 in clang disabled.
> > Despite clang supports DWARF-5 better and for a longer time than GCC.
> I did not take it to mean that. I took it to mean that he isn't going to
> tell other groups what to work on which a change request seems to have
> become. He instead expects them to keep doing what they are doing if they
> want versus getting forced to do what he is working on.
Currently on files built by clang -gdwarf-5 DWZ will fail:
dwz: ./usr/lib64/libmatrix_client.so.0.3.1-0.3.1-2.fc34.x86_64.debug: Unknown debugging
Which is fine as the file just does not get optimized. But that results in rpm
size bigger for clang-built binaries by 31.23% as -fdebug-types-section is not
used. If -fdebug-types-section was used for clang-built binaries DWZ would
fail a similar way but the size increase would be "just" by 6.78%.
I had a wrong idea. For clang -flto the option -fdebug-types-section no longer
makes sense as clang produces direct DW_TAG_class references (DW_FORM_ref4).
So DWZ cannot optimize clang output better, DWZ makes sense only for GCC, not
(A bit, DWZ can still find slightly more optimal DW_FORM_* variants than
clang, I will check if it cannot be fixed in clang.)