<div dir="ltr">
One area the proposal doesn't cover is the ELF file format properties. What section type will this be? What flags will it have? Is the output intended to be part of the executable loadable image or not? Does it even need to be in the final executable output, or is it just being in the object sufficient? The same or similar questions arise if you are considering this for other output formats (e.g. COFF, Mach-O etc) for each of them too.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 5 Aug 2020 at 23:36, Kazu Hirata via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><pre style="color:rgb(0,0,0);white-space:pre-wrap">Introduction
============

This RFC proposes a mechanism to dump arbitrary messages into object
files during compilation and retrieve them from the final executable.

Background
==========

We often need to collect information from all object files of
applications.  For example:

- Mircea Trofin needs to collect information from the function
  inlining pass so that he can train the machine learning model with
  the information.

- I sometimes need to dump messages from optimization passes to see
  where and how they trigger.

Now, this process becomes challenging when we build large applications
with a build system that caches and distributes compilation jobs.  If
we were to dump messages to stderr, we would have to be careful not to
interleave messages from multiple object files.  If we were to modify
a source file, we would have to flush the cache and rebuild the entire
application to collect dump messages from all relevant object files.

High Level Design
=================

- LLVM: We provide machinery for individual passes to dump arbitrary
  messages into a special ELF section in a compressed manner.

- Linker: We simply concatenate the contents of the special ELF
  section.  No change is needed.

- llvm-readobj: We add an option to retrieve the contents of the
  special ELF section.

Detailed Design
===============

DumpAccumulator analysis pass
-----------------------------

We create a new analysis pass called DumpAccumulator.  We add the
analysis pass right at the beginning of the pass pipeline.  The new
analysis pass holds the dump messages throughout the pass pipeline.

If you would like to dump messages from some pass, you would obtain
the result of DumpAccumulator in the pass:

  DumpAccumulator::Result *DAR = MAMProxy.getCachedResult<DumpAccumulator>(M);

Then dump messages:

  if (DAR) {
    DAR->Message += "Processing ";
    DAR->Message += F.getName();
    DAR->Message += "\n";
  }

AsmPrinter
----------

We dump the messages from DumpAccumulator into a section called
".llvm_dump" in a compressed manner.  Specifically, the section
contains:

- LEB128 encoding of the original size in bytes
- LEB128 encoding of the compressed size in bytes
- the message compressed by zlib::compressed

in that order.

llvm-readobj
------------

We read the .llvm_dump section.  We dump each chunk of compressed data
one after another.

Existing Implementation
=======================

<a href="https://reviews.llvm.org/D84473" target="_blank">https://reviews.llvm.org/D84473</a>

Future Directions
=================

The proposal above does not support the ThinLTO build flow.  To
support that, I am thinking about putting the message as metadata in
the IR at the prelink stage.

Thoughts?</pre></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>