search for: filearchive

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

Patch extracts MSB/LSB info from /bin/file output and passes it as separate parameret from elf_arch. Then it is sent to impl_file_architecture 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

...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 oth...

Patch extracts MSB/LSB info from /bin/file output and passes it as separate parameret from elf_arch. Then it is sent to impl_file_architecture 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)

...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 that...

...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, a...

The previously library-side ‘file_architecture’ API is reimplemented in the daemon, in OCaml. There are some significant differences compared to the C implementation: - The C code used libmagic. That is replaced by calling the ‘file’ command (because that is simpler than using the library). - The C code had extra cases to deal with compressed files. This is not necessary since the

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, - "ELF.*(?:executable|shared object|relocatable), (.+?),", 0)

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 ++

If libmagic isn't installed then the guestfs_file_architecture API doesn't work. This means that inspection will always return <arch>unknown</arch> for every guest. This subtly breaks a few features. In particular it was reported that the virt-builder/virt-customize --install option did not work because the "unknown" architecture of the guest was not compatible

...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 ? There i...

--- 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 use at run time." }; InitISOFS,

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, - "ELF.*(MSB|LSB).*(?:executable|shared object|relocatable),

When parts of the daemon were previously converted to OCaml, the previous PCRE regexps were converted to Str regexps. Restore the original PCRE regexps. There was also one case where an original call to glob(3) was replaced by a Str regexp, and this is replaced by a PCRE regexp (although it is in fact identical in this instance). This updates commit b48da89dd6edce325f4c1f2956435c4d383ebe77 and

...> 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 ar...