Reduce Dwarf Debug Size

[Mike Stump]

On Feb 28, 2007, at 2:03 PM, Daniel Jacobowitz wrote:
> I don't think the patch is a good direction.  The basic model of - 
> frepo makes more sense, though the actual implementation of  
> collect2 doesn't seem like a good fit.  Didn't Apple work on a  
> 'symbol database' concept at one point?

Yes.  Fully debugging information in an sql lite db,

> My overall mental model for this problem, which I've spent quite a  
> long time thinking about but very little time fixing, goes like this:
>
>   - Have a symbol database per "project".

Sounds like -frepo.  My model of -frepo includes -frep=my-project- 
repo.db.

>   - When compiling a file, generate complete debug info for each  
> included header iff the database says it is not yet output,

Sounds like the repo optimization where, given a database for the  
entire project above, you opportunistically output things if they  
haven't been output already, in the first pass.  One is free to do  
this with repo and is an orthogonal speedup.

>     or if (magic happens) it appears to be stale.  (other magic
>     happens) to handle including files with different #define's
>     that would affect the debug info.  Note, incompatible with
>     omitting unused information.

Not incompatible with it from my perspective, worse case, one might  
see extra recompiles.

>   We generate bigger debug info this way but a lot less overall.

By doing it based upon first need, trivially, there isn't any extra.

>   - Generate that debug info either into objects, or into the
>     symbol database, which is more complicated but more flexible if
>     multiple binaries get linked from the same object files.  In
>     practice maybe that means one debug file per .o file.

One has to be very careful to not engineer a scheme that is 10x  
slower at compiling.  We have implementation experience with the  
debug into in the sqllite db approach.  Let's just say, I think the - 
frepo extension is better.