On 19/09/12 13:18, Eitan Adler wrote:
Under what circumstances can the binary change but the build-id remain the
same? I'm aware of line number, and file path differences in the debug info.
Is there anything else?
differing -frandom-seed options perhaps?
If you've changed the command line the
On 19 September 2012 05:43, Andrew Stubbs wrote:
> On 18/09/12 22:59, Mike Frysinger wrote:
>>
>> the linker's --build-id and associated .note.gnu.build-id section. you
>> can't
>> hash the entire object because it can change between compiles. build-id
>> lets
>> you say "regardless of the hash
On 18/09/12 22:59, Mike Frysinger wrote:
the linker's --build-id and associated .note.gnu.build-id section. you can't
hash the entire object because it can change between compiles. build-id lets
you say "regardless of the hash of the entire object, we know the content that
matters is unchanged"
On Tuesday 18 September 2012 17:07:53 Andrew Stubbs wrote:
> On 18/09/12 21:04, Mike Frysinger wrote:
> > On Tuesday 18 September 2012 08:44:29 Andrew Stubbs wrote:
> >> Clearly there are some technical challenges in doing this: we'd have to
> >> hash all the object files and libraries (a la direct
On 18/09/12 21:04, Mike Frysinger wrote:
On Tuesday 18 September 2012 08:44:29 Andrew Stubbs wrote:
Clearly there are some technical challenges in doing this: we'd have to
hash all the object files and libraries (a la direct mode), but those
problems are surmountable, I think.
or just re-use b
On Tuesday 18 September 2012 08:44:29 Andrew Stubbs wrote:
> Clearly there are some technical challenges in doing this: we'd have to
> hash all the object files and libraries (a la direct mode), but those
> problems are surmountable, I think.
or just re-use build-id ...
> The linker does not use
On 18/09/12 16:37, Justin Lebar wrote:
ldcache would hash object files and spit out linked files. It would
use an entirely separate cache. Its handling of command-line options
would be entirely different. Its processing of input files would be
entirely different. ISTM that very little would b
> What I'm looking for is more concrete
> roadblocks I haven't considered.
You'd basically have to rewrite all of ccache.
ccache hashes header files and spits out object files.
ldcache would hash object files and spit out linked files. It would
use an entirely separate cache. Its handling of c
On 18/09/12 15:31, Justin Lebar wrote:
So, again, before I waste my time implementing this feature, are there any
other fundamental gotchas that would prevent it ever working or ever being
useful?
On a large project with many inputs to ld, you'd have to hash a /lot/
of object files, increasing
> So, again, before I waste my time implementing this feature, are there any
> other fundamental gotchas that would prevent it ever working or ever being
> useful?
On a large project with many inputs to ld, you'd have to hash a /lot/
of object files, increasing the overhead of ccache substantially
Hi all, again,
I've just posted about improving compile speed by caching compiler
failures, and in the same vein I'd like to consider caching
called-for-link compile tasks.
This is partly interesting for the many small autoconf tests, but is
also increasingly interesting for real compilation
11 matches
Mail list logo
