[llvm-dev] [cfe-dev] [PATCH/DRAFT] Embed metadata into object file
Mehdi Amini via llvm-dev
llvm-dev at lists.llvm.org
Tue Apr 5 08:33:21 PDT 2016
> On Apr 5, 2016, at 7:51 AM, Christian Dietrich <dietrich at cs.fau.de> wrote:
>
> Mehdi Amini <mehdi.amini at apple.com> writes:
>
>> Worded like that, I can see a close analogy with "Debug Info".
>
> Indeed, it is very similar, but there are some differences and
> shortcoming, if a developer only wants to smuggle some metadata out in a
> very specific format:
>
> For the IR->ELF path, the debug information is encoded as Dwarf (or
> something else) in the binary. The plugin developer has not much
> control about the binary format of the data. !llvm.extra_sections
> would give a quite fine-grained control.
>
> For the AST->IR path, I don't see an easy way to annotate a few pieces
> of information in the AST without spinning up the whole
> debug-information generation process.
Yes, I meant conceptually it is the same as debug info, so it makes sense to solve it the same way (i.e. metadata + backend support for codegen).
>
>>> [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.
>>
>> You can write clang plugin that are LLVM pass and insert them in the
>> pipeline.
>
> I can? How? I have not seen any possibility to inject a LLVM pass into
> the Clang CodeGen PassManager infrastructure from a clang plugin, which
> is also FrontentAction like CodeGen.
The FrontendAction is totally separated from the LLVM-pass, but I don’t see why your plugin can’t contain both.
To load an LLVM pass into the pipeline, see what Polly is doing for instance: http://polly.llvm.org/example_load_Polly_into_clang.html
—
Mehdi
>
>>
>>> I think it would be useful for many analyzes
>>> to have access both to the AST and to the IR.
>>
>> This is more fuzzy to me, I don't know enough about clang but I'm not
>> sure the design allow to keep a link from the IR to the clang AST? (If
>> it is the case, I'd be curious to see how it works).
>
> If you restrict the possible subjects to top-level functions, global
> variables, and the compilation unit, this should be implementable quite
> straight forward.
>
> chris
> --
> 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