search for: filearch

Newer versions of file slightly changed the output, removing the comma between the type, and the architecture string. Tweak the regular expression so: - the comma is optional, but if missing then only the architecture string will follow - the architecture string has no commas --- daemon/filearch.ml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daemon/filearch.ml b/daemon/filearch.ml index b2c30ae87..a892ba851 100644 --- a/daemon/filearch.ml +++ b/daemon/filearch.ml @@ -25,7 +25,7 @@ open Unix_utils open Utils let re_file_elf = - PCRE.compile "ELF (\\d+)-bit...

...cture and checked/ Modified magic_for_file to handle regex changes. Now with tests for file_architecture. Fixes: RHBZ#1211996 Maros Zatko (2): inspector: recognize ppc64 and ppc64le archs (RHBZ#1211996) tests: ppc64 and ppc64le for file_architecture generator/actions.ml | 8 ++++++++ src/filearch.c | 24 +++++++++++++++--------- 2 files changed, 23 insertions(+), 9 deletions(-) -- 1.9.3

...es. If lld should be usable as a library, I assume it should not leaks any memory when performing a single link pass (UniversalDriver::link(arc, argv)). Actually, after calling that function, I got some major leaks. I may be wrong, but I think there is 3 major leaks. - One of the main leak is in FileArchive. When calling the find() method, FileArchive returns a non-owned pointer that is never deleted by the caller. The problem is that find() is a virtual method but does not properly define who is responsible of the returned pointer. So some implementations return a pointer to internal storage, and...

...chitecture and checked/ Modified magic_for_file to handle regex changes. Now with tests for file_architecture, and error reporting for unknown endianness. Fixes: RHBZ#1211996 Maros Zatko (1): inspector: recognize ppc64 and ppc64le archs (RHBZ#1211996) generator/actions.ml | 8 ++++++++ src/filearch.c | 28 +++++++++++++++++++--------- 2 files changed, 27 insertions(+), 9 deletions(-) -- 1.9.3

...mbers are force loaded or not. The ReaderArchive ::parseFile() method will check the force-load option, if true it will parse up all the members and return an vector<> of File* objects, one for each member. If force-load is not specified, ReaderArchive ::parseFile() will just return one FileArchive object which is a subclass of ArchiveLibraryFile. The find() method of that class will search the table of contents and return a File* object for the member defining the requested symbol, or nullptr if nothing in the archive defines that symbol. > > I think the first set of features t...

...rchive then, the linker has to invoke the appropriate Reader that has been created a) Hooks are needed to determine if the input file is an archive library, Should there be a function in ReaderArchive to check if the InputFile is an archive library ? b) InputFiles is a vector of Files, FileArchive doesnot derive from file, is a seperate vector needed ? b) lld also has to invoke variation of parseFile function so that it returns a FileArchive instead of a vector of files, how does lld need to invoke ? c) If it returns a vector of files as specified in the ReaderArchiveOptions...

...sed content (this is a consequence of the change above). This commit demonstrates a number of techniques which will be useful for moving inspection code to the daemon: - Moving an API from the C library to the OCaml daemon. - Calling from one OCaml API inside the daemon to another (from ‘Filearch.file_architecture’ to ‘File.file’). This can be done and is done with C daemon APIs but correct reply_with_error handling is more difficult in C. - Use of Str for regular expression matching within the appliance. --- daemon/Makefile.am | 2 + daemon/filearch.ml | 137 +++++...

It looks like there are errors in the buildbot runs with std::future_error when executing lot of tests, probably we can disable it for now to make the buildbot clean ? http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-ubuntu-13.04/builds/26755/steps/test/logs/stdio has more information. Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by

It's pretty weird -- I can't reproduce this on my machine. Can you? I can only speculate a cause. But I'll try to disable the feature to see if buildbot will get back to green. On Thu, Feb 26, 2015 at 9:08 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > It looks like there are errors in the buildbot runs with std::future_error > when executing lot of tests,

On Wednesday, 14 September 2016 15:50:20 CEST Richard W.M. Jones wrote: > --- LGTM, just one question below. > + else if (strstr (elf_arch, "UCB RISC-V")) { > + ret = safe_asprintf (g, "riscv%s", bits); > + goto no_strdup; > + } Is this bit of output from `file` reliable at this point, or can it change in the future? I recall the RISC-V is a

On Wednesday, 14 September 2016 15:50:20 CEST Richard W.M. Jones wrote: > --- Ah, I forgot one thing: > + else if (strstr (elf_arch, "UCB RISC-V")) { > + ret = safe_asprintf (g, "riscv%s", bits); > + goto no_strdup; > + } I guess the "riscv16", "riscv32", and "riscv64" should be documented for the

--- src/filearch.c | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/src/filearch.c b/src/filearch.c index 8fb1acf..ce9d0a1 100644 --- a/src/filearch.c +++ b/src/filearch.c @@ -59,14 +59,14 @@ cleanup_magic_t_free (void *ptr) # endif COMPILE_REGEXP (re_file_elf, -...

Unfortunately I was unable to build s390 binaries since multilib was dropped in Fedora 24 on s390x. Going from the source of the 'file' command it seems as if it prints "32-bit" (the architecture is really 31 bit). --- generator/actions.ml | 12 ++++++++++++ src/filearch.c | 10 ++++++++++ test-data/Makefile.am | 2 ++ test-data/binaries/Makefile.am | 2 ++ test-data/binaries/bin-s390x-dynamic | Bin 0 -> 8448 bytes test-data/binaries/lib-s390x.so | Bin 0 -> 7696 bytes 6 files changed, 26 insertions(+) cr...

...omize --install option did not work because the "unknown" architecture of the guest was not compatible with the host. libmagic is a small, widely available C library, so the easiest fix is just to make it mandatory. Reported by: Solarix on IRC --- docs/guestfs-building.pod | 2 +- lib/filearch.c | 20 -------------------- m4/guestfs_libraries.m4 | 7 ++++--- 3 files changed, 5 insertions(+), 24 deletions(-) diff --git a/docs/guestfs-building.pod b/docs/guestfs-building.pod index eba5ec8..53a4d94 100644 --- a/docs/guestfs-building.pod +++ b/docs/guestfs-building.pod @@ -177...

...ve 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 so that it returns a FileArchive instead of a vector of files, how does lld need to invoke ? Ther...

--- generator/actions.ml | 8 ++++++++ src/filearch.c | 28 +++++++++++++++++++--------- 2 files changed, 27 insertions(+), 9 deletions(-) diff --git a/generator/actions.ml b/generator/actions.ml index 4447de6..6648d63 100644 --- a/generator/actions.ml +++ b/generator/actions.ml @@ -788,6 +788,10 @@ to specify the QEMU interface emulation to...

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 looks like there have been discussions and small sketches done on reading archive

--- src/filearch.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/src/filearch.c b/src/filearch.c index 5985b73..cbc8372 100644 --- a/src/filearch.c +++ b/src/filearch.c @@ -56,14 +56,16 @@ cleanup_magic_t_free (void *ptr) # endif COMPILE_REGEXP (re_file_elf, -...

...stance). This updates commit b48da89dd6edce325f4c1f2956435c4d383ebe77 and commit eeda6edca19ea02ffea7f433501dd063e04cd819 and commit 2ca0fa778de5e748f4545eddf9798e7a723fe07e. --- daemon/Makefile.am | 14 ++++++++++---- daemon/btrfs.ml | 14 +++++++------- daemon/daemon-c.c | 6 ++++++ daemon/filearch.ml | 14 +++++++------- daemon/md.ml | 4 ++-- 5 files changed, 32 insertions(+), 20 deletions(-) diff --git a/daemon/Makefile.am b/daemon/Makefile.am index 1f7cb2277..fc1389f67 100644 --- a/daemon/Makefile.am +++ b/daemon/Makefile.am @@ -187,7 +187,8 @@ guestfsd_LDFLAGS = \ -L$(shell $(O...

...> I have other related changes coming next, but I would like to tackle > them one at a time. > Here's an update. After http://reviews.llvm.org/D8372 , I updated the profiling data. https://people.freebsd.org/~davide/llvm/lld-03162015.svg It seems now 85% of CPU time is spent inside FileArchive::buildTableOfContents(). In particular, 35% of the samples are spent inserting into unordered_map, so there's maybe something we can do differently there (e.g. , Rui's proposal of a concurrent map doesn't seem that bad). Thanks, -- Davide "There are no solved problems; there...