search for: 0x8359000

...= 0 open("temp.GNU.a-O1Q6E8", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 close(4) = 0 *** SIGNAL HANDLING REMOVED *** open("temp.GNU.a-O1Q6E8", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 brk(0) = 0x8357000 brk(0x8359000) = 0x8359000 fstat64(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40019000 _llseek(4, 0, [0], SEEK_CUR) = 0 _llseek(4, 0, [0], SEEK_SET) = 0 _llseek(4, 0, [0], SEEK_SET)...

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

...robably an llvm::sys::Path issue. > > *** SIGNAL HANDLING REMOVED *** > > open("temp.GNU.a-O1Q6E8", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 Open yet again the temnporary file into which we'll build the symtab. > brk(0) = 0x8357000 > brk(0x8359000) = 0x8359000 > fstat64(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > 0) = 0x40019000 This mmap is just allocating memory > _llseek(4, 0, [0], SEEK_CUR) = 0 > _llseek(4, 0,...

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