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

[Robinson, Paul]

> 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?

Hm, actually stuffing the string in the debug info is a thought, you could do it
as a global constant entry. If the string had an adequately unique weird prefix
you wouldn't even have to parse the DWARF, just scan .debug_str for it.
 
> >
> > 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?

Not generating debug info in a release build is moderately common; are you
willing to not have a compilation database that reflects release builds?
If you want that, you'd need to fiddle Clang enough to produce skeleton debug
info even when the command line doesn't have -g in it.
--paulr

>
> -- Sean Silva