<div dir="ltr">On Tue, Jul 23, 2013 at 12:50 PM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> > I think there are tools that strip unused symbols from binaries, and I<br>

> > suspect these would be fairly widely used in embedding toolchains. My limited<br>
> > experience with such toolchains leads me to the conclusion that mucking with<br>
> > binaries in any fashion isn't going to reliably solve the build-chain.<br>
><br>
> The fact of the matter is that clang can emit a string in a call to printf (or<br>
> whatever) that definitely won't get removed.<br>
<br>
</div>That's because there's a reference to the string from the generated code for the<br>
printf call.  if the printf call doesn't get removed, it follows that the parameters<br>
it uses won't get removed.<br>
<div class="im"><br>
> Since clang would be adding this information itself, it can embed the string in<br>
> the same way to ensure it isn't removed.<br>
<br>
</div>If you're willing to codegen a reference to the compilation database string from<br>
some function somewhere, that isn't going to be removed, yeah.<br>
<div class="im"><br>
> A tool that recursively walks an entire directory tree would still work in the<br>
> case of embedded; basically by definition software with such tight size constraints<br>
> that needs this kind of step is going to be a simple local build (it isn't big<br>
> enough to require distributed), and so you can just walk the build directory.<br>
<br>
</div>Or the software is bulging at the seams and requires extra measures to shrink<br>
small enough to fit.  It could be huge. Sometimes games are like that.<br>
Whether a compilation-database string in the object file would survive depends<br>
on where you put it (.rodata? .comment? .my_new_subsection?) and whether that<br>
place gets munged by some size-reduction step (symbol-stripping, dead-stripping,<br>
whatever).<br></blockquote><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think the idea of stuffing the info into the object file has merit, fwiw.<br>
It's worth pursuing if there's some reasonably large subset of environments<br>
that can benefit from it.  Doesn't have to work everywhere.<br></blockquote><div><br></div><div>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?</div>
<div><br></div><div>-- Sean Silva</div></div></div></div>