[llvm-commits] PCH fix
Tanya M. Lattner
tonic at nondot.org
Thu May 17 11:08:48 PDT 2007
> This patch is good. I installed this patch in mainline sources. I agree, this
> should also go in 2.0 release branch.
Devang - Can you please apply this patch to the release-2.0 branch? Also,
it would be great if we could push this to the mirror ASAP, so I can begin
making new tarballs tonight. I think Bill might be able to do that if you
> Thanks Anton for taking care of this bug.
> On May 17, 2007, at 2:53 AM, Anton Korobeynikov wrote:
>> Hello, Everyone.
>> Attached patch fixes PCHs for both TOT and 2.0 release.
>> There were 2 problems:
>> 1. flush() method of oFILEstream doesn't actually flush the file. This
>> can lead to incorrect offsets calculations in the PCH handling code and
>> junk output. This problem seems to be highly platform-dependent: it
>> fails for linux & mingw32, but passes for darwin.
>> There are two possible solutions: either use stdio_sync_buf for
>> oFILEstream or flush the asm_out_file by hands. I preferred second.
>> 2. This problem is not platform specific. We have the following sequence
>> of calls during PCH's read:
>> 1) llvm_start_asm_file()
>> 2) llvm_read_pch()
>> 3) llvm_end_asm_file()
>> In llvm_start_asm_file() routine 2 FunctionPassManagers
>> (PerFunctionPasses and CodeGenPasses) are created having TheModule used
>> during construction, later in the llvm_read_pch() TheModule is freed and
>> recreated, but ... PassManagers still holds pointer to old module. This
>> causes uninitialised memory reads (and segfaults later) during
>> doFinalization() calls in the llvm_end_asm_file().
>> The solutions was: factor out passmanagers' creation code to separate
>> routine and call it in llvm_read_pch() in order to recreate passes.
>> I think, this patch should be propagated to 2.0 release branch, or,
>> otherwise PCHs should be marked as "broken in 2.0".
>> Patch tested with Qt compilation on x86/linux.
More information about the llvm-commits