GCOV and stripping debug info

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

GCOV and stripping debug info

Manuel Klimek via cfe-dev
Implementing GCOV in the new pass manager  (r322126) I'm wondering whether the addition of a "StripSymbols(OnlyDebugInfo = true)" pass is needed - and maybe that functionality in general can be removed?

It was added, I believe, before we had the "NoDebug" style debug info, used specifically for profiling, optimization remarks, etc. So when this was implemented, stripping the debug info was probably necessary to avoid actually emitting debug info into the resulting object files.

This could be useful in an LTO like build, if you know the debug info is not needed at the LTO stage - strip it out at the end of the frontend compile to reduce the size of bitcode files.

So... does this seem relevant here? In general? (I haven't looked at what other uses)

Totally happy to port the StripSymbols pass to the new pass manager if it seems like it's useful/necessary.

- Dave

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: GCOV and stripping debug info

Manuel Klimek via cfe-dev


> On Jan 10, 2018, at 11:40 AM, David Blaikie <[hidden email]> wrote:
>
> Implementing GCOV in the new pass manager  (r322126) I'm wondering whether the addition of a "StripSymbols(OnlyDebugInfo = true)" pass is needed - and maybe that functionality in general can be removed?
>
> It was added, I believe, before we had the "NoDebug" style debug info, used specifically for profiling, optimization remarks, etc. So when this was implemented, stripping the debug info was probably necessary to avoid actually emitting debug info into the resulting object files.
>
> This could be useful in an LTO like build, if you know the debug info is not needed at the LTO stage - strip it out at the end of the frontend compile to reduce the size of bitcode files.

You mean that for LTO scheduling an explicit StripSymbols pass is an advantage over just using the NoDebug, which only causes the baclkend to ignore it? But the debug info will probably be needed for optimization remarks during LTO time, wouldn't it?

>
> So... does this seem relevant here? In general? (I haven't looked at what other uses)

As one datapoint, I didn't know we had StripSymbols(OnlyDebugInfo = true) as a pass (I only knew about the llvm::stripDebugInfo() functions). Grepping for other uses of StripSymbols and stripDebugInfo might be a good start.

-- adrian
>
> Totally happy to port the StripSymbols pass to the new pass manager if it seems like it's useful/necessary.
>
> - Dave

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: GCOV and stripping debug info

Manuel Klimek via cfe-dev


On Wed, Jan 10, 2018 at 11:48 AM Adrian Prantl <[hidden email]> wrote:


> On Jan 10, 2018, at 11:40 AM, David Blaikie <[hidden email]> wrote:
>
> Implementing GCOV in the new pass manager  (r322126) I'm wondering whether the addition of a "StripSymbols(OnlyDebugInfo = true)" pass is needed - and maybe that functionality in general can be removed?
>
> It was added, I believe, before we had the "NoDebug" style debug info, used specifically for profiling, optimization remarks, etc. So when this was implemented, stripping the debug info was probably necessary to avoid actually emitting debug info into the resulting object files.
>
> This could be useful in an LTO like build, if you know the debug info is not needed at the LTO stage - strip it out at the end of the frontend compile to reduce the size of bitcode files.

You mean that for LTO scheduling an explicit StripSymbols pass is an advantage over just using the NoDebug, which only causes the baclkend to ignore it? But the debug info will probably be needed for optimization remarks during LTO time, wouldn't it?

Right - though you could be doing a build that doesn't have remarks enabled, but wanted debug info locations for something that's frontend-only? I don't know the full diversity of uses of NoDebug debug info, but could imagine there might be uses (not sure if there are current uses - could be future uses, but that's nothing to worry much about/design for of course) that only need it for the frontend compile.
 

>
> So... does this seem relevant here? In general? (I haven't looked at what other uses)

As one datapoint, I didn't know we had StripSymbols(OnlyDebugInfo = true) as a pass (I only knew about the llvm::stripDebugInfo() functions). Grepping for other uses of StripSymbols and stripDebugInfo might be a good start.

*nod*
 

-- adrian
>
> Totally happy to port the StripSymbols pass to the new pass manager if it seems like it's useful/necessary.
>
> - Dave


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: GCOV and stripping debug info

Manuel Klimek via cfe-dev
In reply to this post by Manuel Klimek via cfe-dev
On 10 January 2018 at 11:40, David Blaikie via cfe-dev <[hidden email]> wrote:
Implementing GCOV in the new pass manager  (r322126) I'm wondering whether the addition of a "StripSymbols(OnlyDebugInfo = true)" pass is needed - and maybe that functionality in general can be removed?

It was added, I believe, before we had the "NoDebug" style debug info, used specifically for profiling, optimization remarks, etc. So when this was implemented, stripping the debug info was probably necessary to avoid actually emitting debug info into the resulting object files.

Correct. I'm not familiar with NoDebug beyond your description in this thread, but it sounds like the right thing to use now.

This could be useful in an LTO like build, if you know the debug info is not needed at the LTO stage - strip it out at the end of the frontend compile to reduce the size of bitcode files.

So... does this seem relevant here? In general? (I haven't looked at what other uses)

Totally happy to port the StripSymbols pass to the new pass manager if it seems like it's useful/necessary.

- Dave

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

smime.p7s (6K) Download Attachment