search for: readons

Any idea what the problem could be? Is there anything more i could do to encircle the problem? Or perhaps is the information i provided uncomplete? Am 25.01.2018 um 16:24 schrieb Thomas Robers: > Hi, > > Am 24.01.2018 um 23:39 schrieb Josef 'Jeff' Sipek: >> It looks like the binaries are stripped.? There should be a "debug" >> package >> you can

On Wed, Jan 24, 2018 at 18:55:47 +0100, Thomas Robers wrote: > Am 23.01.2018 um 20:07 schrieb Josef 'Jeff' Sipek: > > On Tue, Jan 23, 2018 at 14:03:27 -0500, Josef 'Jeff' Sipek wrote: > > > On Tue, Jan 23, 2018 at 18:21:38 +0100, Thomas Robers wrote: ... > > > 1. Do you have any idea what the imap process was doing at the time of the > > >

The DoesntAccessMemoryFns and OnlyReadsMemoryFns tables are used by alias analysis to specify which standard functions don't access memory or only read memory. However gcc now automatically supplies this information to us. I checked on my x86 linux box what gcc gives for the functions listed in those tables. While gcc mostly agrees with them, there are the following differences (using

Hi, Am 24.01.2018 um 23:39 schrieb Josef 'Jeff' Sipek: > It looks like the binaries are stripped. There should be a "debug" package > you can install with symbol information. Then, the backtrace should be much > more helpful. I installed the debug package and the backtrace now is: --- snip --- (gdb) bt full #0 0x00007f73f1386495 in raise () from /lib64/libc.so.6 No

I declare some checkboxes : <%= check_box_tag ''offers[]'', offer.id , @params[:offers].include?(offer.id.to_s) ,:readonly=>true %> the result is : <input checked="checked" id="offers[]" name="offers[]" readonly="readonly" type="checkbox" value="1" /> But readonly doesn''t work ??? -- Posted

The previous patch argued that globally affecting .can_write based on '-r' (the global 'readonly') prevents the ability for a filter to call next_open(nxdata, true) to purposefully write to the plugin, even while advertising .can_write=0 to the client. But it also demonstrated that when a filter passes false to next_open, we were still making needless probes into the plugin, for

To allow filters to modify the export name as it passes through the layers this commit makes several changes: The filter .open callback now takes an extra parameter, the export name. This is always non-NULL (for oldstyle it is ""). This string has a short lifetime and filters that need to hang on to it must take a copy. The filter must pass the exportname parameter down to the next

Now that we can differentiate content based on export name, we also need to be able to differentiate content for a --tls=on server, since TLS is optional according to whether the client has authenticated. For internal code and filters, this means adding a new parameter; the sh plugin can do likewise. For plugins, we can't add a parameter until the V3 protocol, so in the meantime, we add

I'm about to add an 'exportname' filter, and in the process, I noticed a few shortcomings in our API. Time to fix those before the 1.22 release locks our API in stone. Overloading .list_exports in order to determine a canonical export name at .open time is awkward; the two uses (answering NBD_OPT_LIST for a full list, vs. remapping a client's "" into a canonical name

Hi, I am trying to understand how assume shaped arrays are received and processed in LLVM IR. I am using "flang" for my front end. There seems to be an array descriptor received as implicit argument for every assume shaped array. For my test routine: ---snip-- SUBROUTINE test(a,b,Li,Lj,Istr,Iend,Jstr,Jend) INTEGER, INTENT(IN) :: Li,Lj INTEGER, INTENT(IN) :: Istr, Iend,

Seeing `g.add_drive_opt :readonly => 1` allows one to imply that ensuring writable access to drive should happen via `g.add_drive_opt :readonly => 0`. However, the passed option value gets passed down to C according to Ruby Boolean semantics, that is, any value apart from `false` and `nil` will be true (see RTEST in Ruby C API). So its more idiomatic and provides a better hint if we use

On 08/03/2015 18:07, Daniel Berlin wrote: > > > On Sun, Mar 8, 2015 at 9:55 AM, Nicholas Chapman > <admin at indigorenderer.com <mailto:admin at indigorenderer.com>> wrote: > > Hi all, > I have identified what seems to be a limitation of LLVM with > regard to marking 'sret functions' as pure/readonly. > > For some context - I have

On Fri, Jul 31, 2015 at 3:53 PM, Philip Reames <listmail at philipreames.com> wrote: > > I'm wondering if there's a problematic interaction with CSE here. > Consider this example is pseudo LLVM IR: > v1 = load i64, %p, !invariant.group !Type1 > ; I called destructor/placement new for the same type, but that optimized > entirely away > p2 =

Hi all, I have identified what seems to be a limitation of LLVM with regard to marking 'sret functions' as pure/readonly. For some context - I have some JITed code produced by LLVM, and that code calls back into the host application occasionally. Since my language is purely functional, no functions have side-effects. Therefore I would like to be able to cache the value of identical

Hi Holger, > Note that I did specify "-g", but not any "-Ox" switches. That > made the size of all *.o files together being 143 MB. LLVM represents debug info as explicit calls to intrinsics. This approach has many advantages, but a possible disadvantage is that it can significantly increase the size of the bitcode. I don't know if that explains your observations.

Hi, All, These four patches are all related to ocfs2 on hard readonly mount. patch 1 fix oops when umount ocfs2 on hard readonly device. Because ocfs2_dismount_volume() will call ocfs2_cluster_hangup() and then call ocfs2_stack_driver_put(), will hit BUG_ON(active_stack == NULL). patch 2 fix oops when do ls or cat in ocfs2 on hard readonly device. Because ocfs2_open_lock() will call

Hello Is there a way to mount a directory as readonly when using LXC with libvirt? Something like: <filesystem type="mount"> <source dir="/sw/py27/python2.7_x86_64"/> <target dir="/opt//py27"/> <readonly/> </filesystem> The documentation says

Hi I am trying to Run AsteriskNow 1.5 which uses Centos 5.3 Distribution with Readonly Root Filesytem. Right now if I shutdown the system abrupty or there is power failure linux kernel doesn't not boot "Kernel panic" and other short of issues.prb due to corrupted files. Thats why i want to make root filesystem as read-only and placing some directories /var and /etc/asterisk etc as

On Tuesday 11 March 2014 23:13:46 Richard W.M. Jones wrote: > diff --git a/src/drives.c b/src/drives.c > index 2c85b52..68e37f7 100644 > --- a/src/drives.c > +++ b/src/drives.c > @@ -115,7 +115,8 @@ static struct drive * > create_drive_file (guestfs_h *g, const char *path, > bool readonly, const char *format, > const char *iface,

LLVM today does not clearly specify if a function specified to not write to memory (i.e. readonly or readnone) is allowed to throw exceptions. LangRef is ambiguous on this issue. The normative statement is "[readnone/readonly functions] cannot unwind exceptions by calling the C++ exception throwing methods" which does not decide an answer for non C++ languages. It used to say (h/t