search for: identify_magic

All files cannot be identified with a magic though. For example Linker scripts, and currently YAML files. On 10/9/2013 1:36 PM, Rui Ueyama wrote: > I guess in each isMyFormat(), you would check the given file's magic using > llvm::sys::fs::identify_magic(), and then check if it's a known value for > that reader. That would be repeated in each isMyFormat(), which is not very > good. > > I'd do that using a mapping from file magic to reader. I mean, we could > call identify_magic() at some central place, look up the mapping, an...

I guess in each isMyFormat(), you would check the given file's magic using llvm::sys::fs::identify_magic(), and then check if it's a known value for that reader. That would be repeated in each isMyFormat(), which is not very good. I'd do that using a mapping from file magic to reader. I mean, we could call identify_magic() at some central place, look up the mapping, and then dispatch. On Wed...

Hi, We have a whole bunch of readers(we would have some more too), and was thinking if we should have a vector of Readers, and have a function isMyFormat in each of them. Any reader that knows to handle, goes ahead and parses the file. On a side note, we currently use .objtxt as an figure out if the file is a YAML file or not. I have added FIXME's in the code, if we could some kind of

...ons for other kinds of yaml files (such as mach-o in yaml). With linker scripts we are stuck with there being no magic at the start and no standard file extension. For new yaml files that we are inventing we should define a standard file extension. I agree with Rui that we should not be calling identify_magic() in every reader. Another approach is to just call each reader to try to parse until one succeeds. The first reader should be the native reader (e.g. ELF or mach-o), so that in the real world there is no time wasted looking at test case formats. -Nick

...Crash Address: 0x604000000776 Crash State: llvm::StringMapImpl::LookupBucketFor std::pair<llvm::StringMapIterator<unsigned int>, bool> llvm::StringMap<unsigned llvm::DWARFContext::create Crash Type: Heap-buffer-overflow READ 4 Crash Address: 0x60300000011c Crash State: llvm::identify_magic llvm::object::ObjectFile::createObjectFile _start clang-fuzzer: https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=label%3AProj-llvm+clang-fuzzer&colspec=ID+Type+Component+Status+Proj+Reported+Owner+Summary&cells=ids Crash Type: Stack-buffer-overflow READ 1 Crash Address: 0x7...

...At this point, I would just have a static method in ReaderArchive the says whether the file is an archive or not. Then have ReaderELF call that method and if it returns true, call through to a ReaderArchive (passing the ReaderELF object as an option in the ReaderOptionsArchive). Also, there is an identify_magic() function in llvm/Support that may help. > b) InputFiles is a vector of Files, FileArchive doesnot derive from file, is a seperate vector needed ? FileArchive should derive from ArchiveLibraryFile which derives from File. > b) lld also has to invoke variation of parseFile function...

...ndard file extension. Isnt having a YAML file starting with the below better, so that you dont need to go through file extensions. magic : arch: You would also be able to figure out if the yaml file is a valid input for the flavor/target too. > I agree with Rui that we should not be calling identify_magic() in every reader. Another approach is to just call each reader to try to parse until one succeeds. The first reader should be the native reader (e.g. ELF or mach-o), so that in the real world there is no time wasted looking at test case formats. Agree. This is better. Thanks Shankar Easwaran

Hi Nick, Here is my understanding, 1) lld-core creates a ReaderOptionsArchive class with the (Reader, CommandLine options flag) 2) lld-core creates an object of type ReaderArchive(ReaderOptions), that users would subclass (off ArchiveLibraryFile) a) GNUArchiveLibrary b) BSDArchiveLibrary b) MachOArchiveLibrary c) COFFArchiveLibrary 3) ReaderArchive has two functions

On Oct 19, 2012, at 3:41 PM, Shankar Easwaran wrote: > Hi, > > I have started to work on support for Reading archive libraries in lld and thought of using the llvm/lib/ArchiveReader for this. > > The ArchiveReader doesnot fully support GNU archive libraries (thin archives), do you think we should continue using llvm/lib/ArchiveReader ? > > I was chatting with Michael and

...or > > std::pair<llvm::StringMapIterator<unsigned int>, bool> > > llvm::StringMap<unsigned > > llvm::DWARFContext::create > > > > Crash Type: Heap-buffer-overflow READ 4 > > Crash Address: 0x60300000011c > > Crash State: > > llvm::identify_magic > > llvm::object::ObjectFile::createObjectFile > > _start > > > > clang-fuzzer: > > https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q= > label%3AProj-llvm+clang-fuzzer&colspec=ID+Type+Component+Status+Proj+ > Reported+Owner+Summary&cells=id...