Repository navigation
Unsound bitcode collection when a single file is compiled multiple times #58
Description
Activity
GLLVM however only produces only one
.foo.c.{o,bc}tuple, meaning that theget-bc-collected bitcode for bothfoo.exeandfoo.patched.exeis the same (whichever targetmakeran last).To be more precise: GLLVM actually produces two tuples, but clobbers the first (the
foo.exeone) with the second (foo.patched.exe).I wonder if we can please all of the build systems all of the time. If the output was called
foo_patchedrather than
foo.patched, we'd be OK, right?I wonder if we can please all of the build systems all of the time. If the output was called
foo_patchedrather than
foo.patched, we'd be OK, right?I'm not 100% sure -- I think the confusion happens with the source files, since GLLVM special-cases the "single" compilation mode and will clobber
.foo.c.oand.foo.c.bcregardless of the output target.- added a commit that references this issue
on Mar 2, 2022 Yeah you are right.
GLLVM doesn't currently distinguish between multiple compilations of the same input file in a single build. For example, imagine the following:
When
make allis run,foo.cis compiled twice: once with-DPATCHED=1and once without.GLLVM however only produces only one
.foo.c.{o,bc}tuple, meaning that theget-bc-collected bitcode for bothfoo.exeandfoo.patched.exeis the same (whichever targetmakeran last).I think the solution here is to rewrite GLLVM's object and bitcode file emission to use content-addressed filenames, rather than path-computed filenames.