search for: gmlt

...hen the actual option was added. I'll try to relay my memory of that discussion, but you might need to track it down or involve some of the other people who participated in it. Honestly, this thread is probably not the best place to rehash the entire design of this feature... > 1) what is -gmlt option designed for? debugging, profiling, autofdo. Do we > expect more use cases for -gmlt? > It was designed for all users of debug information that merely need location information rather than variable, type, or other debug information. We expect these to at least include any and everythi...

On Thu, Aug 28, 2014 at 11:51 AM, Alexey Samsonov <vonosmas at gmail.com> wrote: > This sounds great. Teaching backend about the -gmlt might help us in > another way: we might enforce full debug info generation in the frontend > for -fsanitize= flags, then rely on some parts of this debug info in > instrumentation passes and prune it before the actual object file > generation. This would be somewhat similar to what -Rp...

On Fri, Oct 24, 2014 at 4:06 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > Diego, > > 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. > > 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. > FWIW, I strongly disagree...

I'm not sure if this was intended, but it's going to be a problem for sample profiles. When we compile with -gmlt, the profiler expects to find the line number for all the function headers so that it can compute relative line locations for the profile. The tool that reads the ELF binary is not finding them, so it writes out absolute line numbers, which are impossible to match during the profile-use phase. Th...

In an effort to fix inlined information for backtraces under DWARF Fission in the absence of the split DWARF (.dwo) files, I'm planning on adding -gmlt-like data to the .o file, alongside the skeleton CU. Since that will involve teaching the LLVM about -gmlt (moreso than it already has - the debug info LLVM metadata already describes -gmlt for the purposes of omitting pubnames in that case) I figured I'd take the opportunity to move the exist...

...Blaikie <dblaikie at gmail.com> wrote: > On Fri, Oct 24, 2014 at 2:48 PM, Diego Novillo <dnovillo at google.com> > wrote: > >> I'm not sure if this was intended, but it's going to be a problem for >> sample profiles. >> >> When we compile with -gmlt, the profiler expects to find the line number >> for all the function headers so that it can compute relative line locations >> for the profile. >> >> The tool that reads the ELF binary is not finding them, so it writes out >> absolute line numbers, which are impossibl...

...gt; On Fri, Oct 24, 2014 at 2:48 PM, Diego Novillo <dnovillo at google.com> >>> wrote: >>> >>>> I'm not sure if this was intended, but it's going to be a problem for >>>> sample profiles. >>>> >>>> When we compile with -gmlt, the profiler expects to find the line >>>> number for all the function headers so that it can compute relative line >>>> locations for the profile. >>>> >>>> The tool that reads the ELF binary is not finding them, so it writes >>>> out ab...

...optimization abilities. >> >> The work on debug information may help you get the information >> you need, but I do not think we will provide information on stack >> frames that have been removed via inlining or tail call. >> >> >> In theory, at -gmlt we should emit enough debug info to give you >> accurate stack traces including inlined frames. Tail calls I assume >> we can't do anything about. > Tail calls I'm not too worried about. I'm reasonably sure that our > existing optimizer doesn't do any tail call...

...villo at google.com> > >>>> wrote: > >>>>> > >>>>> I'm not sure if this was intended, but it's going to be a problem for > >>>>> sample profiles. > >>>>> > >>>>> When we compile with -gmlt, the profiler expects to find the line > >>>>> number for all the function headers so that it can compute relative > line > >>>>> locations for the profile. > >>>>> > >>>>> The tool that reads the ELF binary is not finding t...

...s optimization abilities. >>>> >>>> The work on debug information may help you get the information you need, but I do not think we will provide information on stack frames that have been removed via inlining or tail call. >>> >>> >>> In theory, at -gmlt we should emit enough debug info to give you accurate stack traces including inlined frames. Tail calls I assume we can't do anything about. >> >> Tail calls I'm not too worried about. I'm reasonably sure that our existing optimizer doesn't do any tail call optimization...

...lt;dnovillo at google.com> >>>>> wrote: >>>>>> >>>>>> I'm not sure if this was intended, but it's going to be a problem for >>>>>> sample profiles. >>>>>> >>>>>> When we compile with -gmlt, the profiler expects to find the line >>>>>> number for all the function headers so that it can compute relative line >>>>>> locations for the profile. >>>>>> >>>>>> The tool that reads the ELF binary is not finding them, so i...

...tack traces with file names and line numbers, but would introduce less overhead. Cary Coutant made a patch which does this for GCC (it didn't hit trunk yet) - reduces debug info to only descriptions of functions, extern variables, line number tables and inlined subroutine info by setting "-gmlt" ("minimum line table") or "-g1" flags. (See this patch at http://old.nabble.com/-patch--Add-new--gmlt-option-for-min.-debug-info-with-line-tables-(issue4440072)-td31482851.html or http://codereview.appspot.com/4440072). This patch is used in Google for about 2 years alread...

On Wed, Aug 27, 2014 at 4:53 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Wed, Aug 27, 2014 at 4:40 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> DW_AT_frame_base (the location of the frame pointer - is that needed for >> symbolication?) > > > I think this is used by libunwind style stack unwinders in conjunction > with

...>>> > >>>> The work on debug information may help you get the information you > need, but I do not think we will provide information on stack frames that > have been removed via inlining or tail call. > >>> > >>> > >>> In theory, at -gmlt we should emit enough debug info to give you > accurate stack traces including inlined frames. Tail calls I assume we > can't do anything about. > >> > >> Tail calls I'm not too worried about. I'm reasonably sure that our > existing optimizer doesn't do a...

...h file names and line numbers, > but would introduce less overhead. Cary Coutant made a patch which does this for GCC (it didn't hit trunk yet) - > reduces debug info to only descriptions of functions, extern variables, line number tables and inlined subroutine info > by setting "-gmlt" ("minimum line table") or "-g1" flags. > (See this patch at http://old.nabble.com/-patch--Add-new--gmlt-option-for-min.-debug-info-with-line-tables-(issue4440072)-td31482851.html > or http://codereview.appspot.com/4440072). This patch is used in Google for about 2 ye...

Just working on some of the gmlt+fission debug info stuff and I came across a comment that might be relevant to reducing the number of distinct debugloc metadata nodes: "or some sub-optimal metadata that // isn't structurally identical (see: file path/name info from clang, which // includes the directory of the cpp f...

...ing most of LLVM’s > optimization abilities. > > The work on debug information may help you get the information you > need, but I do not think we will provide information on stack > frames that have been removed via inlining or tail call. > > > In theory, at -gmlt we should emit enough debug info to give you > accurate stack traces including inlined frames. Tail calls I assume we > can't do anything about. Tail calls I'm not too worried about. I'm reasonably sure that our existing optimizer doesn't do any tail call optimizations. G...

...urate stack trace while utilizing most of LLVM’s optimization abilities. > > The work on debug information may help you get the information you need, > but I do not think we will provide information on stack frames that have > been removed via inlining or tail call. > In theory, at -gmlt we should emit enough debug info to give you accurate stack traces including inlined frames. Tail calls I assume we can't do anything about. > Moreover, if at some point you also need the values of the arguments of a > removed stack frame, this seems heroic to be able to provide such &g...

For -Rpass, and other related uses, I am looking at enabling column info by default. David pointed me at PR 14106, which seems to be the original motivation for introducing -gcolumn-info. However, I am finding no differences when using it on this test. I've tried building with/without -gcolumn-info and found almost no difference in compile time (+0.4%): $ /usr/bin/time clang -w -fno-builtin

So, after many shenanigans, we finally have -gmlt-like inline summary debug info in .debug_info when using -gsplit-dwarf (see r221306). Hooray \o/ Testing this with asan, it seems to be working: Given a simple example of inlining failure: $ cat asan.cpp __attribute__((always_inline)) inline void func(int* i) { *i = 3; } int main() { func(null...