<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 24, 2014 at 4:06 PM, Xinliang David Li <span dir="ltr"><<a href="mailto:xinliangli@gmail.com" target="_blank">xinliangli@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":7zb" class="a3s" style="overflow:hidden">Diego,<br><br>I think sampleFDO needs to be designed in a way which can protect itself from future breakage like this. The roots in the unnecessary dependency of sample FDO on gmlt setting. It is totally reasonable to tune debug binary size by changes like this.<div><br></div><div>The right way is to fix this is to introduce an internal -g<...> flag for use by sampleFDO -- it will have a fixed definition of what needs to be emitted.</div></div></blockquote></div><br></div><div class="gmail_extra">FWIW, I strongly disagree.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The more modes we have, the harder everything will be to support and keep track of. The wide variety of modes used for debug information is already really challenging to support and maintain. We shouldn't make it harder, and less-used flags seem like the wrong direction.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">At a higher level, I don't think "sample profiling" or "asan" are good ways to design a set of debug information that we want emitted in a particular mode. Instead, we should look at what fundament information a collection of tools need access to. Both sample profiling, the sanitizers, and crash backtraces need access to a very minimal amount of information consisting of line tables, and that is how we designed '-gline-tables-only' (the LLVM flag name).</div><div class="gmail_extra"><br></div><div class="gmail_extra">And I think that both this design and Dave's change are totally fine. There was only one thing we missed: a very particular use case for line tables that had a particular usage pattern. The problem here is that we don't have any profile *collection* tests in LLVM. There are some reasons for that (its hard, etc) but we could probably work on improving it. But the correct path is the one Dave and Diego identified -- the information *is* still there, we just need a more clever way of extracting it. And (in addition) we should probably add some testing strategy for this. =]</div></div>