[llvm-dev] [cfe-dev] [PATCH/DRAFT] Embed metadata into object file

Christian Dietrich via llvm-dev llvm-dev at lists.llvm.org
Fri Apr 1 05:20:03 PDT 2016


Adrian Prantl <aprantl at apple.com> writes:

> Depending on your needs, just using a global with the “section”
> attribute might also work for you:
> http://llvm.org/docs/LangRef.html#global-variables

I was aware of that possibility. But, there are several drawbacks to
using global variables and the current infrastructure from a clang
plugin's point of view:

1. It feels like a hack. It is not an idiomatic way of transporting
   information alongside with an translation unit.

2. A clang plugin is mostly defined by it's ASTConsumer; there is no
   direct access to the produced LLVM intermediate representation. I
   would have to insert AST elements that result in the attributed
   global variable. [1]

3. A more idealistic problem I have with this solution is that we change
   the actual (semantic) content of the module. But I only want to carry
   _metadata_ about the module alongside.

4. There already is an good metadata infrastructure in LLVM and a very
   good attribute infrastructure in clang. Why not utilize them?

So my question is:

   I want to generate and attach (structured) metadata at every point in
   life cycle (AST, LLVM module, object file) of a module and retrieve it
   from the compilation results. How can I do that?

At the moment, my patches are only a proposal to solve this for a very
specifc use case (mine): attaching single strings. I think, furthermore,
that it would also be handy to materialize and retrieve more complex
metadata types to/from object files. For example, we could serialize
LLVM metadata trees into separate sections:

   !llvm.extra_sections = {!0}
   !0 = !{!"clang.myanalysis", !1, !2}
   !1 = !{ i32 15, i32 28, i32 142}
   !2 = !{!"key", i32 10000, !"key2", i32 9999}

I'm not sure whether this would be useful and reusable for others. So:
Do you think this would be useful for other developers as well?

chris


[1] This is a _seperate_ drawback of clang plugins at the moment: They
    cannot define an LLVM IR transformation that should be applied when
    the plugin is active. I think it would be useful for many analyzes
    to have access both to the AST and to the IR.
-- 
Christian Dietrich, M.Sc. (Wissenschaftlicher Mitarbeiter)
Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme)
Friedrich-Alexander-Universität Erlangen-Nürnberg
Martensstr. 1
91058 Erlangen

Tel:    (09131) 85-27280
Fax:    (09131) 85-28732
eMail:  christian.dietrich at fau.de
WWW:    http://www4.cs.fau.de/~dietrich


More information about the llvm-dev mailing list