search for: error_codes

On Fri, May 18, 2012 at 3:07 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > >> +  error_code ec = sys::fs::status(filePathTwine, stat); > > stat is undefined if ec isn't success. ec will be success even in the case of > file_not_found. Actually I was wrong. The Windows and UNIX implementation disagree on this point. I'm going to change it to match

On Thu, May 17, 2012 at 3:25 PM, Nick Kledzik <kledzik at apple.com> wrote: > I now have an implementation of FileOutputBuffer (OutputBuffer was already taken).  The patch supports the functionality listed below and I've tested that it works for lld. > > To implement the FileOutputBuffer, I needed to add some more functions to llvm/Support/FileSystem.h, including: >  

This is a proposed patch to enhance FileSystem.h to add functionality (getting and setting permission bits and mapping an unmapping files). This implementation follows the N3365 proposal regarding permission bits. This functionality is needed for my next patch which will implement llvm/include/Support/FileOutputBuffer.h which is needed by lld. -------------- next part -------------- A

I now have an implementation of FileOutputBuffer (OutputBuffer was already taken). The patch supports the functionality listed below and I've tested that it works for lld. -------------- next part -------------- A non-text attachment was scrubbed... Name: FileOutputBuffer.patch Type: application/octet-stream Size: 25308 bytes Desc: not available URL:

On Jun 16, 2012, at 3:51 PM, Chris Lattner wrote: > On Jun 15, 2012, at 3:48 PM, Nick Kledzik wrote: > >> In lld we have a Reader class which is a factory that takes .o file(s) and produces an in memory lld::File object(s). But in doing so, there could be I/O errors (file not readable) or file may be malformed. We are also using C++11 in lld, so we use std::unique_ptr for managing

In lld we have a Reader class which is a factory that takes .o file(s) and produces an in memory lld::File object(s). But in doing so, there could be I/O errors (file not readable) or file may be malformed. We are also using C++11 in lld, so we use std::unique_ptr for managing object ownership. The Reader class currently has an interface that can be simplified down to: virtual error_code

On Jun 15, 2012, at 3:48 PM, Nick Kledzik wrote: > In lld we have a Reader class which is a factory that takes .o file(s) and produces an in memory lld::File object(s). But in doing so, there could be I/O errors (file not readable) or file may be malformed. We are also using C++11 in lld, so we use std::unique_ptr for managing object ownership. > > The Reader class currently has an

On Tue, Apr 28, 2020 at 05:16:34PM +0200, Joerg Roedel wrote: > @@ -302,9 +313,13 @@ void do_boot_page_fault(struct pt_regs *regs, unsigned long error_code) > * - User faults > * - Reserved bits set > */ > - if (error_code & (X86_PF_PROT | X86_PF_USER | X86_PF_RSVD)) { > + if (ghcb_fault || > + error_code & (X86_PF_PROT | X86_PF_USER | X86_PF_RSVD)) { >

On Tue, Apr 28, 2020 at 05:16:34PM +0200, Joerg Roedel wrote: > @@ -302,9 +313,13 @@ void do_boot_page_fault(struct pt_regs *regs, unsigned long error_code) > * - User faults > * - Reserved bits set > */ > - if (error_code & (X86_PF_PROT | X86_PF_USER | X86_PF_RSVD)) { > + if (ghcb_fault || > + error_code & (X86_PF_PROT | X86_PF_USER | X86_PF_RSVD)) { >

Hi All, I've been thinking lately about how to improve LLVM's error model and error reporting. A lack of good error reporting in Orc and MCJIT has forced me to spend a lot of time investigating hard-to-debug errors that could easily have been identified if we provided richer error information to the client, rather than just aborting. Kevin Enderby has made similar observations about the

Use NOKPROBE_SYMBOL macro to protect functions from kprobes instead of __kprobes annotation in trap.c. This also applies __always_inline annotation for some cases, because NOKPROBE_SYMBOL() will inhibit inlining by referring the symbol address. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> Cc: Thomas Gleixner <tglx at linutronix.de> Cc: Ingo Molnar <mingo at

On Mon, Jun 18, 2012 at 1:22 PM, Nick Kledzik <kledzik at apple.com> wrote: > On Jun 16, 2012, at 3:51 PM, Chris Lattner wrote: >> On Jun 15, 2012, at 3:48 PM, Nick Kledzik wrote: >> >>> In lld we have a Reader class which is a factory that takes .o file(s) and produces an in memory lld::File object(s).  But in doing so, there could be I/O errors (file not readable)

There are several libraries in LLVM that create their own `error_code` categories, so that they can return errors in a consistent way and with convenient messages. To do this, these libraries create an error category type that inherits from `_do_message` in system_error.h. There are a number of ways that this is wrong: 1. From the name, it's quite clear that _do_message is an implementation

One could even debate whether reserved bit faults are always fatal (and should never be propagated to the guest)... Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2008-01-28/xen/arch/x86/traps.c =================================================================== --- 2008-01-28.orig/xen/arch/x86/traps.c 2008-01-28 11:31:44.000000000 +0100 +++ 2008-01-28/xen/arch/x86/traps.c

On Jun 18, 2012 1:24 PM, "Nick Kledzik" <kledzik at apple.com> wrote: > > On Jun 16, 2012, at 3:51 PM, Chris Lattner wrote: > > On Jun 15, 2012, at 3:48 PM, Nick Kledzik wrote: > > > >> In lld we have a Reader class which is a factory that takes .o file(s) and produces an in memory lld::File object(s). But in doing so, there could be I/O errors (file not

Hi all, I''ve been looking at the performance of my fb app and one glaring issue seems to be with the parsing speed of rexml in processing the results. Has anyone looked into porting the facebooker parser from rexml to libxml? If not, any reason I shouldn''t try? Thanks! Yu-Shan. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Mehdi, > I’m not sure to understand this claim? You are supposed to be able to extend and subclass the type of diagnostics? (I remember doing it for an out-of-tree LLVM-based project). You can subclass diagnostics, but subclassing (on its own) only lets you change the behaviour of the diagnostic/error itself. What we need, and what this patch supplies, is a way to choose a particular

...ide can recover or fail gracefully. That means we >> need >> >> to be able to serialize an error with enough information to describe what >> >> went wrong. There's no practical way to maintain a serialization routine >> for >> >> all possible std::error_codes that might come up, even if they were >> powerful >> >> enough to describe everything that could go wrong (which again, being >> static >> >> kinds, they're not). With my proposal however, a JITError base class can >> be >> >> defined as: &g...

Hi Mehdi, > If you subclass a diagnostic right now, isn’t the RTTI information available to the handler, which can then achieve the same dispatching / custom handling per type of diagnostic? > (I’m not advocating the diagnostic system, which I found less convenient to use than what you are proposing) I have to confess I haven't looked at the diagnostic classes closely. I'll take a

Hi, sys::fs::create_directories() recurses infinitely for relative paths with only one directory or where the first directory in path doesn't exist. This was observed in r153176. Example: #include <llvm/Support/FileSystem.h> using namespace llvm; int main(int argc, char *argv[]) { bool existed; error_code ec = sys::fs::create_directories(Twine("log"), existed);