[LLVMdev] llvm-ranlib: Bus Error in regressions + fix

Evan Jones ejones at uwaterloo.ca
Wed Nov 23 15:03:40 CST 2005


On Nov 23, 2005, at 12:08, Reid Spencer wrote:
>> However, it would be possible to use a stringstream for this.
> Aggg! No! Those perform horribly with anything more than a small 
> amount of data. Some Archive files can be huge (e.g. not fit in 
> memory).

An archive can be too big to fit in memory? That would be a BIG 
library. In that case, building a temporary in memory is a bad idea, 
but then so is copying it twice, as is being done now. Maybe it really 
would be better to scan over everything and build the symbol table, and 
then scan over everything again and build the final archive. This would 
avoid writing an extra copy out to disk, and it wouldn't be hard to do 
this.

>> This is not necessary using the replace method described above. 
>> However, it *would* be necessary on Windows since you can't 
>> unlink/replace an open file on that platform. To fix this, the 
>> original archive file must be closed before performing the move.
> Yup. If you use the sys::Path class to do the "unlink" 
> (removeFromDisk) then the platform differences should be accounted 
> for. Please don't put the direct unlink call into ArchiveWriter.cpp.

So this comment means that I should attempt to theoretically support 
Windows, and close the current archive file before updating it?

>> I've attached a patch that builds the temporary archive in a 
>> stringstream, then writes the temporary file and moves it into place. 
>> It fixes the bug on the old RedHat system.
> Please test the performance of that on the large .a file in the 
> regression tests. I have my doubts about the scalability and speed for 
> stringstream. Why can't you just write it out directly to the 
> temporary file?

I'll remove the stringstream, but this means that I need to create two 
temporary files. However, this change is less invasive, so I'll rework 
my patch again.

Evan Jones

--
Evan Jones
http://evanjones.ca/



More information about the LLVMdev mailing list