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

Evan, Your patch uses an operating system call that is not portable. All non-portable code needs to be located in the lib/System library. I'm not sure why this problem appears on an old Red Hat system. Perhaps the C++ io library is not up to snuff on that platform? What compiler are you using? Reid. Evan Jones wrote: > I ran the LLVM regression tests today (via make check) and

On Nov 22, 2005, at 23:59, Reid Spencer wrote: >> = {0, >> 0, 4, 0}}} >> (gdb) p archPath >> $3 = {path = {static npos = 4294967295, >> _M_dataplus = {<allocator<char>> = {<No data fields>}, >> _M_p = 0x83545f4 "temp.GNU.a5\b"}, static _S_empty_rep_storage = > What's with the "5\b" at the end? Looks

On Nov 23, 2005, at 8:16, Evan Jones wrote: > (4) Write the foreignST into the TmpArchive file. Is there any reason > that this isn't possible? Then the final archive would be created in a > single pass, and it could just be moved into place. Ah. I see: It needs to be written in order to compute the offsets. However, it would be possible to use a stringstream for this. I think

Evan Jones wrote: > On Nov 22, 2005, at 19:10, Reid Spencer wrote: > >> 1. What is the path name associated with TmpArchive? If its the same >> as the path name associated with archPath then that's a bug, probably >> introduced when Path::makeUnique is called from >> Path::createTemporaryFileOnDisk which is called from line 377 of >> ArchiveWriter.cpp.

On Nov 22, 2005, at 19:10, Reid Spencer wrote: > 1. What is the path name associated with TmpArchive? If its the same > as the path name associated with archPath then that's a bug, probably > introduced when Path::makeUnique is called from > Path::createTemporaryFileOnDisk which is called from line 377 of > ArchiveWriter.cpp. This does not appear to be the problem. I

Evan Jones wrote: > On Nov 23, 2005, at 8:16, Evan Jones wrote: > >> (4) Write the foreignST into the TmpArchive file. Is there any reason >> that this isn't possible? Then the final archive would be created in a >> single pass, and it could just be moved into place. > > > Ah. I see: It needs to be written in order to compute the offsets. Exactly. >

On Nov 22, 2005, at 17:18, Reid Spencer wrote: > Your patch uses an operating system call that is not portable. All > non-portable code needs to be located in the lib/System library. Yep! I know. That is why I posted it for discussion. I'm not sure if this is the "right" way to fix the problem, or if there is a different fix that should be applied (like perhaps copying the

Evan Jones wrote: > I am pretty certain that this has nothing to do with the C++ library, > and everything to do with the behaviour of mmap when the file that was > mmaped is modified. I actually can reproduce this behaviour with the > attached C test case. The program mmaps a file called 'data,' prints the > last byte, truncates the file, then tries to read the last

Fixing one bug uncovers the next one... To reproduce: llvm-ar rc ./libgcc.a libgcc/./_muldi3.o <and-lots-more-.o-files...> The result: C:\msys\1.0\home\llvm_home\install\bin\llvm-ar.exe: Can't move './libgcc.a-000003' to './libgcc.a-000002': Cannot create a file when that file already exists. So apparently, we're trying to move one file on top of another. The

Evan Jones wrote: > 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

Yep, you found another bug. Unlike Unix, Windows does not allow a file to be implicitly replaced via renaming. I'll fix it. Greg Pettyjohn wrote: > Fixing one bug uncovers the next one... > > To reproduce: > llvm-ar rc ./libgcc.a libgcc/./_muldi3.o <and-lots-more-.o-files...> > > The result: > C:\msys\1.0\home\llvm_home\install\bin\llvm-ar.exe: Can't move

On Nov 23, 2005, at 18:17, Reid Spencer wrote: >> So this comment means that I should attempt to theoretically support >> Windows, and close the current archive file before updating it? > If you use sys::Path, it is not "theoretically" supported, it is > supported. Well, except of course that it isn't currently possible to build LLVM on Windows. Hence this is a

Hello, The documentation for llvm-ar says that option 'z' is used to compressed a file before archiving it. I did some tests with different input files (text and LLVM bitcode) and found the archive to be about the same size as the input. When debugging I found that the compressed flag gets passed to several calls and eventually makes it to Archive::writeMember() but this function

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

On Thu, 2005-01-27 at 13:16, Henrik Bach wrote: > c:\projects\build\MinGW\llvm-4-1\Debug\bin\llvm-ar.exe: > c:/projects/build/MinGW/llvm-4-1/Debug/lib/libc.bca-000000: Can't destroy > file (hb:2): The process cannot access the file because it is being used by > another process. > make[3]: *** [/C/projects/build/MinGW/llvm-4-1/Debug/lib/libc.bca] Error 2 >

>From: Jeff Cohen Date: Wed, 26 Jan 2005 19:47:44 -0800 > >Fixed. Yes, now it isn't the path. I've recorded this trace: ------------------------- llvm[3]: Building Debug Bytecode Archive libc.bca /bin/rm -f /C/projects/build/MinGW/llvm-4-1/Debug/lib/libc.bca /C/projects/build/MinGW/llvm-4-1/Debug/bin/llvm-ar rcsf /C/projects/build/MinGW/llvm-4-1/Debug/lib/libc.bca

On Mon, Jul 30, 2012 at 8:15 PM, Martinez, Javier E <javier.e.martinez at intel.com> wrote: > Hello, > > > > The documentation for llvm-ar says that option ‘z’ is used to compressed a > file before archiving it. I did some tests with different input files (text > and LLVM bitcode) and found the archive to be about the same size as the > input. When debugging I found

Hello, llvmdev! I'm using LLVM on OpenBSD. This project proactively advocates usage of 'secure' C apis, especially related to memory bounds checking. Thus using functions like sprintf/strcpy/etc usually spits out a linker warning in base toolchain like this one: /home/proger/dev/llvm/Debug+Asserts/lib/libclangFrontend.a(DocumentXML.o) (.text+0xc65): In function

The mapped files weren't being closed at all; they were only being unmapped. It's now fixed. Reid Spencer wrote: >On Thu, 2005-01-27 at 13:16, Henrik Bach wrote: > > >>c:\projects\build\MinGW\llvm-4-1\Debug\bin\llvm-ar.exe: >>c:/projects/build/MinGW/llvm-4-1/Debug/lib/libc.bca-000000: Can't destroy >>file (hb:2): The process cannot access the file

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached