llvm dev - Apr 2012 - [LLVMdev] How to strip all unused debugging metadata?

When I generate debug information for a source file that has a number of static
functions that are unused, all of the debugging metadata that I generated for
them during initial compilation remains even after the source function
definitions have been stripped out of the IR.  (e.g. in the MD for
DW_TAG_compile_unit's list of subprograms, each of those functions' info
is still in the list, and so forth).  How can I remove that unused stuff?  (It
continues on to generated object files, which is extra undesirable when there is
a lot of this.)

I would have expected that the strip-dead-debug-info pass would take care of
this, but it doesn't make a difference--looking at its implementation, it
just iterates over llvm.dbg.gv and llvm.dbg.sp and removes entries from there
that are unused.  In my case, DIBuilder doesn't seem to be declaring
llvm.dbg.sp in the first place--is the a symptom of a problem?

Thanks,
-matt

On 24 April 2012 16:04, Matt Pharr <matt.pharr at gmail.com>
wrote:
> When I generate debug information for a source file that has a number of
static functions that are unused, all of the debugging metadata that I generated
for them during initial compilation remains even after the source function
definitions have been stripped out of the IR.  (e.g. in the MD for
DW_TAG_compile_unit's list of subprograms, each of those functions' info
is still in the list, and so forth).  How can I remove that unused stuff?  (It
continues on to generated object files, which is extra undesirable when there is
a lot of this.)
In theory, every metadata that is not attached to a real value (or a
named metadata) is stripped out. I think even if they're not in gv/sp
arrays, but I'm not sure.

Are you sure there isn't any path to a real value from the dangling
metadata? Do you create named metadata?

> I would have expected that the strip-dead-debug-info pass would take care
of this, but it doesn't make a difference--looking at its implementation, it
just iterates over llvm.dbg.gv and llvm.dbg.sp and removes entries from there
that are unused.  In my case, DIBuilder doesn't seem to be declaring
llvm.dbg.sp in the first place--is the a symptom of a problem?
I'd assume that has nothing to do with it. Not sure it's a strict
requirement to produce the gv/sp arrays. Have you tried producing them
and linking all your metadata in it to see if the dangling ones get
removed?

-- 
cheers,
--renato

http://systemcall.org/

On Apr 24, 2012, at 5:36 AM, Renato Golin wrote:
> On 24 April 2012 16:04, Matt Pharr <matt.pharr at gmail.com> wrote:
>> When I generate debug information for a source file that has a number
of static functions that are unused, all of the debugging metadata that I
generated for them during initial compilation remains even after the source
function definitions have been stripped out of the IR.  (e.g. in the MD for
DW_TAG_compile_unit's list of subprograms, each of those functions' info
is still in the list, and so forth).  How can I remove that unused stuff?  (It
continues on to generated object files, which is extra undesirable when there is
a lot of this.)
> 
> In theory, every metadata that is not attached to a real value (or a
> named metadata) is stripped out. I think even if they're not in gv/sp
> arrays, but I'm not sure.
> 
> Are you sure there isn't any path to a real value from the dangling
> metadata? Do you create named metadata?
I think that the root problem is that there is a path to the metadata (from
llvm.dbg.cu to the metadata for the DW_TAG_compile_unit to the list of
subprograms to the individual DW_TAG_subprogram metadata), but that in turn
there's no longer any need for the DW_TAG_subprogram metadata for all of the
functions that were stripped out.

Perhaps the answer is that I just need to write the code that traverses the
metadata and removes the subprogram metadata from the list of subprograms, if
the corresponding function definition has been stripped from the module. 
I'd have guessed that the DIBuilder infrastructure would have ended up doing
that automagically for me, but maybe that was an incorrect assumption?

Thanks,
-matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120424/5f0409f6/attachment.html>