search for: archivememb

...m is that Path::isValid() will reject a string containing "<" and ">" on Windows. Note that this is not the case on Unix -- compare the implementation of Path::isValid() in .../Unix/Path.inc to the one in .../Win32/Path.inc. Probably the right place to make the fix is in ArchiveMember::ArchiveMember() (Archive.cpp circa line 43). As per the comment this constructor is being used to make a "sentry node" in an ilist. In the initializations you will see `path("<invalid>")' which on Windows should be something else (perhaps just use `path("--inv...

1. I got the tools to build. Yay! 2. I got past all the annoying trouble with not finding header files. Yay! Now I'm having problems with this: llvm-ar rc ./libgcc.a libgcc/./_muldi3.o <and-lots-more-.o-files...> C:\msys\1.0\home\llvm_home\install\bin\llvm-ar.exe: <invalid>: path is not valid I'm investigating this with the debugger and so far I've learned that

...ct a string containing "<" and ">" on > Windows. > > Note that this is not the case on Unix -- compare the implementation of > Path::isValid() in .../Unix/Path.inc to the one in .../Win32/Path.inc. > > Probably the right place to make the fix is in > ArchiveMember::ArchiveMember() (Archive.cpp circa line 43). > > As per the comment this constructor is being used to make a "sentry node" > in an ilist. In the initializations you will see `path("<invalid>")' which > on Windows should be something else (perhaps just u...

..." on >>> Windows. >>> >>> Note that this is not the case on Unix -- compare the implementation of >>> Path::isValid() in .../Unix/Path.inc to the one in .../Win32/Path.inc. >>> >>> Probably the right place to make the fix is in >>> ArchiveMember::ArchiveMember() (Archive.cpp circa line 43). >>> >>> As per the comment this constructor is being used to make a "sentry >>> node" >>> in an ilist. In the initializations you will see `path("<invalid>")' >>> which >&...

...ot;<" and ">" on >> Windows. >> >> Note that this is not the case on Unix -- compare the implementation of >> Path::isValid() in .../Unix/Path.inc to the one in .../Win32/Path.inc. >> >> Probably the right place to make the fix is in >> ArchiveMember::ArchiveMember() (Archive.cpp circa line 43). >> >> As per the comment this constructor is being used to make a "sentry node" >> in an ilist. In the initializations you will see `path("<invalid>")' which >> on Windows should be something else...

...dows. >>>> >>>> Note that this is not the case on Unix -- compare the implementation of >>>> Path::isValid() in .../Unix/Path.inc to the one in .../Win32/Path.inc. >>>> >>>> Probably the right place to make the fix is in >>>> ArchiveMember::ArchiveMember() (Archive.cpp circa line 43). >>>> >>>> As per the comment this constructor is being used to make a "sentry node" >>>> in an ilist. In the initializations you will see `path("<invalid>")' >>>> which &g...

...================================================ >RCS file: /var/cvs/llvm/llvm/lib/Bytecode/Archive/Archive.cpp,v >retrieving revision 1.6 >diff -u -r1.6 Archive.cpp >--- Archive.cpp 28 Jan 2005 01:17:07 -0000 1.6 >+++ Archive.cpp 21 Apr 2005 15:13:24 -0000 >@@ -40,8 +40,8 @@ > ArchiveMember::ArchiveMember() > : next(0), prev(0), parent(0), path("<invalid>"), flags(0), data(0) > { >- info.user = 1000; >- info.group = 1000; >+ info.user = getuid(); >+ info.group = getgid(); > info.mode = 0777; > info.fileSize = 0; > info.modTi...

...not the case on Unix -- compare the >>>>> implementation of >>>>> Path::isValid() in .../Unix/Path.inc to the one in >>>>> .../Win32/Path.inc. >>>>> >>>>> Probably the right place to make the fix is in >>>>> ArchiveMember::ArchiveMember() (Archive.cpp circa line 43). >>>>> >>>>> As per the comment this constructor is being used to make a >>>>> "sentry node" >>>>> in an ilist. In the initializations you will see >>>>> `path(&quot...

...b/libstdc++.so.5 #2 0x4009c818 in std::basic_filebuf<char, std::char_traits<char> >::xsputn(char const*, int) () from /usr/lib/libstdc++.so.5 #3 0x400cbed1 in std::ostream::write(char const*, int) () from /usr/lib/libstdc++.so.5 #4 0x0829c9d0 in llvm::Archive::writeMember(llvm::ArchiveMember const&, std::basic_ofstream<char, std::char_traits<char> >&, bool, bool, bool) ( this=0x8356088, member=@0x8356180, ARFile=@0xbfffd630, CreateSymbolTable=false, TruncateNames=false, ShouldCompress=false) at ArchiveWriter.cpp:294 #5 0x0829d297 in llvm::Archive...

On Wed, Apr 20, 2005 at 12:12:54PM +0200, Markus F.X.J. Oberhumer wrote: > Misha Brukman wrote: > >On Tue, Apr 19, 2005 at 07:01:40AM +0200, Markus F.X.J. Oberhumer > >wrote: Have you considered using bugpoint for your codegen debugging > >needs? http://llvm.cs.uiuc.edu/docs/Bugpoint.html#codegendebug > > Well, the (critical) bug in question was >

...0x4009c818 in std::basic_filebuf<char, std::char_traits<char> > >::xsputn(char const*, int) () from /usr/lib/libstdc++.so.5 > #3 0x400cbed1 in std::ostream::write(char const*, int) () > from /usr/lib/libstdc++.so.5 > #4 0x0829c9d0 in llvm::Archive::writeMember(llvm::ArchiveMember const&, > std::basic_ofstream<char, std::char_traits<char> >&, bool, bool, bool) ( > this=0x8356088, member=@0x8356180, ARFile=@0xbfffd630, > CreateSymbolTable=false, TruncateNames=false, ShouldCompress=false) > at ArchiveWriter.cpp:294 > #5 0x0829...

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