search for: error_cod

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 http://www.open-std.org...

...ort/FileSystem.h, including: >   is_writable_file() >   is_executable_file() >   set_file_executable() For these parts I would like to follow http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3365.html#TOC which is what the rest of the fs library is modeled after. So we would use: error_code permissions(const Twine &path, perms p); If the name is confusing (it says nothing about modification) I'm fine with modify_permissions or something similar. >   unique_file_sized() Instead of adding this I would much rather add resize_file and call it after unique_file. >   map_...

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:

...n 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 readFile(StringRef path, std::unique_ptr<lld::File> &result); >> >> But this interface has become awkward to use. There are two "return" values. This method is a unique_ptr "source" but the use of a by-refernce parameter means you have to start with an u...

...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 readFile(StringRef path, std::unique_ptr<lld::File> &result); But this interface has become awkward to use. There are two "return" values. This method is a unique_ptr "source" but the use of a by-refernce parameter means you have to start with an uninitialized uniqu...

...ject(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 readFile(StringRef path, std::unique_ptr<lld::File> &result); > > But this interface has become awkward to use. There are two "return" values. This method is a unique_ptr "source" but the use of a by-refernce parameter means you have to start with an uninitial...

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)) { > /* Print some information for debugging */ > - er...

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)) { > /* Print some information for debugging */ > - er...

...tinue work on the MachO side of LLD. I see tackling the error modeling problem as a first step towards improving error handling in general: if we make it easy to model errors, it may pave the way for better error handling in many parts of our libraries. At present in LLVM we model errors with std::error_code (and its helper, ErrorOr) and use diagnostic streams for error reporting. Neither of these seem entirely up to the job of providing a solid error-handling mechanism for library code. Diagnostic streams are great if all you want to do is report failure to the user and then terminate, but they can...

...traps.c +++ b/arch/x86/kernel/traps.c @@ -106,7 +106,7 @@ static inline void preempt_conditional_cli(struct pt_regs *regs) preempt_count_dec(); } -static int __kprobes +static __always_inline int do_trap_no_signal(struct task_struct *tsk, int trapnr, char *str, struct pt_regs *regs, long error_code) { @@ -136,7 +136,7 @@ do_trap_no_signal(struct task_struct *tsk, int trapnr, char *str, return -1; } -static void __kprobes +static void do_trap(int trapnr, int signr, char *str, struct pt_regs *regs, long error_code, siginfo_t *info) { @@ -173,6 +173,7 @@ do_trap(int trapnr, int signr,...

...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 readFile(StringRef path, std::unique_ptr<lld::File> &result); >>> >>> But this interface has become awkward to use. There are two "return" values.  This method is a unique_ptr "source" but the use of a by-refernce parameter means you have to start wi...

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

...=============================================== --- 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 2008-01-30 11:47:39.000000000 +0100 @@ -823,6 +823,17 @@ asmlinkage void do_machine_check(struct machine_check_vector(regs, regs->error_code); } +static inline void reserved_bit_page_fault(int guest, unsigned long addr, + struct cpu_user_regs *regs) +{ + if ( guest ) + gdprintk(XENLOG_ERR, "reserved bit in page table entry: "); + else + dprintk(XENLOG_ERR, &quot...

...e 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 readFile(StringRef path, std::unique_ptr<lld::File> &result); > >> > >> But this interface has become awkward to use. There are two "return" values. This method is a unique_ptr "source" but the use of a by-refernce parameter means you have to start...

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:

...best diagnostic we could produce is "In foo.o: malformed load command at index N". A (straw-man) improved system might look like this: class ObjectError ... { // <- Root of all object-file errors std::string ArchiveName = ""; std::string ObjectName = ""; std::error_code EC; void log(raw_ostream &OS) const override { if (!ArchiveName.empty()) OS << "In archive '" << ArchiveName << "', "; OS << "In object file '" << ObjectName << "', " << EC.messag...

.... This makes it easy to spot mistakes in our error handling and correct them. (2) Error returns should describe all the information about an error that a client could reasonably use to recover from the error. This requirement goes beyond what a flat enum, or even an enum with a category (like std::error_code) is capable of expressing. For example, it is possible to express "missing_file" in an enum, but not "missing_file: /path/to/file". A library client could meaningfully respond to the latter by re-generating the file (if they knew how) and re-trying the operation. (3) There may...

...uce is "In foo.o: malformed load command at index > N". A (straw-man) improved system might look like this: > > class ObjectError ... { // <- Root of all object-file errors > std::string ArchiveName = ""; > std::string ObjectName = ""; > std::error_code EC; > > void log(raw_ostream &OS) const override { > if (!ArchiveName.empty()) > OS << "In archive '" << ArchiveName << "', "; > OS << "In object file '" << ObjectName << "', &...

...e_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); return 0; } recurses infinitely in sys::fs::create_directories(). This happens because the parent of "log" is "" which doesn't exist so the function recurses and looks for the parent or "" wh...