[cfe-dev] [RFC] Embedding compilation database info in object files.

[Sean Silva]

On Tue, Jul 23, 2013 at 12:50 PM, Robinson, Paul <
Paul_Robinson at playstation.sony.com> wrote:

> > > I think there are tools that strip unused symbols from binaries, and I
> > > suspect these would be fairly widely used in embedding toolchains. My
> limited
> > > experience with such toolchains leads me to the conclusion that
> mucking with
> > > binaries in any fashion isn't going to reliably solve the build-chain.
> >
> > The fact of the matter is that clang can emit a string in a call to
> printf (or
> > whatever) that definitely won't get removed.
>
> That's because there's a reference to the string from the generated code
> for the
> printf call.  if the printf call doesn't get removed, it follows that the
> parameters
> it uses won't get removed.
>
> > Since clang would be adding this information itself, it can embed the
> string in
> > the same way to ensure it isn't removed.
>
> If you're willing to codegen a reference to the compilation database
> string from
> some function somewhere, that isn't going to be removed, yeah.
>
> > A tool that recursively walks an entire directory tree would still work
> in the
> > case of embedded; basically by definition software with such tight size
> constraints
> > that needs this kind of step is going to be a simple local build (it
> isn't big
> > enough to require distributed), and so you can just walk the build
> directory.
>
> Or the software is bulging at the seams and requires extra measures to
> shrink
> small enough to fit.  It could be huge. Sometimes games are like that.
> Whether a compilation-database string in the object file would survive
> depends
> on where you put it (.rodata? .comment? .my_new_subsection?) and whether
> that
> place gets munged by some size-reduction step (symbol-stripping,
> dead-stripping,
> whatever).
>

I was thinking more along the lines of "debug info", in that it's a size
hit, but opt-in and for use during development (do you know of any games
that eschew debug info during development for size reasons?). I would
expect the compilation database info to not be larger than debug info
(excruciatingly long compiler command lines are not uncommon though; I
haven't measured). Maybe debug info is a good place to put the compilation
database entries?


>
> I think the idea of stuffing the info into the object file has merit, fwiw.
> It's worth pursuing if there's some reasonably large subset of environments
> that can benefit from it.  Doesn't have to work everywhere.
>

Upthread I identified that the set of environments where both printf and
debug info are available is at least achievable; does that seem like a good
set of environments to target?

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130723/42609831/attachment.html>