search for: outstring

Hi, I am trying to generate the DFG of machine functions. Initially, I added a pass to generate the DFG of LLVM IR functions. This was based on the mail thread - http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025582.html. This pass worked fine and I was able to generate DFG of LLVM IR functions. Later, I ported the DFG pass code for machine functions. I ported the InstIterator.h

I tried debugging it and the issue seems to be in the implementation of MachineInstrIterator.h and the way it interacts with GraphWriter.h functions. I found this by replacing the ( template <> struct GraphTraits<MCDFGraph<MachineFunction*> >) with a similar MCDFGraph based template of CFG similar to the one in MachineFunction.h (similarly replacing the DOTGraphTraits with the

I can use llc to compile my IR module to amdgcn with some non-zero output. However, if try to write the output (assembly or object) to a string (via buffer_ostream) the resulting string has always zero length. Here the code changes I do: Original llc:       if (Target->addPassesToEmitFile(PM, *OS,                                       DwoOut ? &DwoOut->os() : nullptr,

Edwin, thanks, it starts making sense inline comments... Török Edwin wrote: > On 2009-09-06 19:57, Ioannis Nousias wrote: > >> Edwin, >> >> thank you for your effort, but I'm not sure I understand. >> Are you describing a graph traversal problem? Is the data model stored >> in a predecessor/successor fashion, which requires you to 'walk' the

It was brought to my attention that dumping a registry hive causes a lot of time spent in disk I/O activity because iconv_open() and iconv_close() are called for every key. Every iconv_open() call causes /usr/lib/.../gconv/$ENCODING.so to be opened and mapped. The iconv_t handles are now cached in the hive_h struct; they are opened on-demand and re-used. On my ~10 year old Lenovo T60, I have

Hi, I am trying to create a table with information from Shapiro Wilk's test of normality. However, it fails due to lack of sample size, it says, but the way I see it, this is not a problem. (See the table of sample sizes (almost) at the bottom). Applying a different function using a similar ftable call is not a problem (See the bottom table). This is R 2.1.0 on Linux (Gentoo). /Fredrik

+ MLIR dev mailing list since that’s where the OrcJit I’m using is. Thanks for all the details, Lang! What you described is exactly what I’m looking for! Please, MLIR dev, let me know if this debug feature and the solution that Lang describes below is interesting for MLIR. I’ll dig more into the details then but it doesn’t seem too complicated. Thanks, Diego From: Lang Hames [mailto:lhames at

On Fri, Feb 09, 2018 at 01:52:52AM +0100, Hilko Bengen wrote: > It was brought to my attention that dumping a registry hive causes a > lot of time spent in disk I/O activity because iconv_open() and > iconv_close() are called for every key. Every iconv_open() call causes > /usr/lib/.../gconv/$ENCODING.so to be opened and mapped. > > The iconv_t handles are now cached in the

On 2009-09-06 19:57, Ioannis Nousias wrote: > Edwin, > > thank you for your effort, but I'm not sure I understand. > Are you describing a graph traversal problem? Is the data model stored > in a predecessor/successor fashion, which requires you to 'walk' the > graph in order to visit all nodes? (and what happens when you have > disjointed DFGs?). Sorry for the

It was brought to my attention that dumping a registry hive causes a lot of time spent in disk I/O activity because iconv_open() and iconv_close() are called for every key. Every iconv_open() call causes /usr/lib/.../gconv/$ENCODING.so to be opened and mapped. The iconv_t handles are now cached in the hive_h struct; they are opened on-demand and re-used. On my ~10 year old Lenovo T60, I have

Commit-ID: e4610e5e04a3292a48a239be366e7767b64ffdcb Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=e4610e5e04a3292a48a239be366e7767b64ffdcb Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Mon, 27 Oct 2014 12:19:25 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 25 Jan 2019 02:57:21 +0000 [klibc] [BUILTIN] Handle

--- lib/hivex-internal.h | 8 +++++--- lib/utf16.c | 11 +++++++---- 2 files changed, 12 insertions(+), 7 deletions(-) diff --git a/lib/hivex-internal.h b/lib/hivex-internal.h index 4135f58..64fd49a 100644 --- a/lib/hivex-internal.h +++ b/lib/hivex-internal.h @@ -268,11 +268,13 @@ extern size_t * _hivex_return_offset_list (offset_list *list); extern void _hivex_print_offset_list

Commit-ID: 27d0e9f3b74b25e5d2c9f366074edb77b9ef5f9f Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=27d0e9f3b74b25e5d2c9f366074edb77b9ef5f9f Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Mon, 27 Oct 2014 12:19:25 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:54 +0000 [klibc] dash: [BUILTIN]

...n * the parameter DC. The bytes of the instruction are specified in the * parameter Bytes, and contains at least BytesSize number of bytes. The * instruction is at the address specified by the PC parameter. If a valid * instruction can be disassembled, its string is returned indirectly in * OutString whose size is specified in the parameter OutStringSize. This * function returns the number of bytes in the instruction or zero if there was * no valid instruction. */ size_t LLVMDisasmInstruction(LLVMDisasmContextRef DC, uint8_t *Bytes, uint64_t BytesSize, uint64_t...

Sadly, there are elements (hello "gentoo"!) that, during the cleanup.d phase, wipe out almost everything in the /tmp of the guest, including the /tmp/aux where virt-dib mounts the auxiliary data. Since that removal excludes things starting with "in_target" (mostly to avoid wiping the "in_target.d" that disk-image-create itself sets up, then rename our "aux"

Hi , I am using LLVM for my Post Graduate course project on Optimization. I am trying to do some insrtumentation to the bytecode.I 've been going through your Instrumentation code for the past few days in /llvm/lib/Transforms/Instrumentation folder and finally found two ways of instrumentation : 1) injecting LLVM bytecode instructions 2) calling an external C function. I am trying both and

The real sudo does it as well, and leaving them when preserving the environment (-E) maybe breaks the applications, as e.g. chroot will have a TMPDIR path pointing outside of it. --- dib/dib.ml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/dib/dib.ml b/dib/dib.ml index df83ba1..d15cd19 100644 --- a/dib/dib.ml +++ b/dib/dib.ml @@ -301,6 +301,11 @@ if [ -z \"$preserve_env\" ];

...C.  The bytes of the instruction are specified in the >  * parameter Bytes, and contains at least BytesSize number of bytes.  The >  * instruction is at the address specified by the PC parameter.  If a valid >  * instruction can be disassembled, its string is returned indirectly in >  * OutString whose size is specified in the parameter OutStringSize.  This >  * function returns the number of bytes in the instruction or zero if there was >  * no valid instruction. >  */ > size_t LLVMDisasmInstruction(LLVMDisasmContextRef DC, uint8_t *Bytes, >                             uint6...

Hi Aiden, The easiest thing I can do is to point you to the source of the "llvm-mc" tool, which does exactly what you ask in its "-disassemble" mode. The code is rather small, so it should be easy to work out. tools/llvm-mc Cheers, James -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Aidan Steele Sent:

Hi, My apologies if this appears to be a very trivial question -- I have tried to solve this on my own and I am stuck. Any assistance that could be provided would be immensely appreciated. What is the absolute bare minimum that I need to do to disassemble an array of, say, ARM machine code bytes? Or an array of Thumb machine code bytes? For example, I might have an array of unsigned chars -- how