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

[Robinson, Paul]

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

--paulr