On Thu, 28 Jun 2012, Cary Coutant wrote: > [resending in plain text. Sorry, gmail defaulted to HTML.] > > Ping. I'm not looking for commit approval yet, just advice on how > thorough we need to be to support -g and LTO together. > > (What's the right way to send a patch to fix a PR? I'm not even sure > whether you were cc'ed on my response.)
The right way to send a patch to fix a PR is to send it to gcc-patches ;) > > You can't delay producing pubnames this way with LTO. Please fix. > > The obvious problem is that we're calling langhooks.dwarf_name (in > gen_namespace_die) for an anonymous namespace, even with the default > -gno-pubnames. I can fix that by adding a check for want_pubnames just before > the call to add_pubname_string, as in the patch below. But this is still going That's sensible anyways - you avoid useless work. So the patch is ok. But still ... > to ICE if you turn on -gpubnames with -lto. The only way I can think of to fix > that is relax the assert in lhd_decl_printable_name, and just have it return > an > empty string in the DECL_NAMELESS case. That will not produce the right > results > for an anonmyous namespace, but without front-end langhooks available to us > (and until we implement the lazy debug plan), how can we do better? ... produce the pubnames early. I mean, each object you want to have its pubname appear in .pubnames at dwarf2out.c time has to have the pubname "created" by the frontend. As far as I can quickly decipher the "pubname" is what lang_hooks.dwarf_name () returns, right? I'd say we have to bite the bullet at some point (this point?) and add a pointer to debug-format specific data to each tree node we eventually emit debug information for (that is types and decls I presume, both at most those that have the lang_specific pointer - in fact we might re-use that pointer, initially hang off the debug-info ptr from lang_specific data and at free-lang-data time re-link it as gimple-lang-specific). > How much is expected to work today with LTO and -g? Aren't we still stuck with > calling langhooks from dwarf2out.c back-end routines? I can understand that we > don't want to ICE, but what guarantees do we make about debug info Well, LTO and -g is expected to work as to not ICE and produce reasonable debug information up to the point where we cannot create language specific info late. That's what you broke (the not-ICE part). In practice LTO with -g works quite well - you can even debug things. It's of course not perfect, but today only because of lang-hooks used in debug output and because of the issue we have with early inline transforms (BLOCK trees get slightly hosed there, there is a bug about this). Richard.
