search for: patchabl

Reid Kleckner wrote: > I'm assuming this attribute won't affect inlining or other IPO in any > way, but you should probably mention that in the langref. To directly answer this, this is just a *mechanism* to implement linkonce_odr type linkage. This in itself does not imply in IPO restrictions, that should come directly from the linkage type. -- Sanjoy

Thanks for looping me in Eric! If I was going to suggest anything here, I'd like to think about a more general approach than a very specific attribute like this. My preference is something like "patchable-function"="kind,kind,..." (if that's even possible). This allows us to have common infrastructure for being able to implement different kinds of function-level patching routines at the same time or even just generalising this mechanism with the instrumentation attribute(s). It...

[Proposed langref entry] The "patchable-prologue" attribute on a function is a general mechanism to control the form of a function's prologue in ways that make it easy to patch at runtime. Currently only one value is supported: # "hotpatch-compact" If a function is marked with "patchable-prologue"="h...

Hi Eric, Eric Christopher wrote: > Two things: > > a) I'm not against this Great! > b) So, what's your use case? I've got something I'm idly working on with > someone else where we want patchable targets in both prologue and > epilogue (and some other places...), and am thinking of how to make this > someone generic enough to build off of there. We plan to use this to be able to divert control flow from an LLVM compiled function to "somewhere else" where the "somewh...

I think most function redirection patching schemes are going to be mutually incompatible, so I'm not sure it makes sense to make this attribute a comma-separated list. I think Eric's and Dean's use case may be better addressed by a separate attribute. My recollection is that they want to add nop slides to the prologue and epilogue that can be hotpatched to enable and disable

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm wondering if there is a patch for kernel 2.4.3 -- already did a wget -r on the ext3 website and i only see a patch for 2.4.5 and greater. - -- - ----- My pulic GnuPG key (in armor format) can be found at: http://www.alltel.net/~rogerx/index.html My ICQ UIN# = 21252173 Created with Linux Mandrake 8.0! http://www.linux-mandrake.com/

[Let's keep the replies on the mailing list] On Fri, Feb 06, 2015 at 11:06:45AM +0000, Margaret Lewicka wrote: > https://gist.github.com/shulima/981973b7500b2adaac88 Just a note that the the file which is patched here is actually generated, so the source file in git is `generator/java.ml'. In Fedora, we have something called java-1.8.0-openjdk-headless. Is that the same as Java[doc]

On Mon, Feb 09, 2015 at 10:56:54AM +0100, Pino Toscano wrote: > On Friday 06 February 2015 10:03:37 Richard W.M. Jones wrote: > > On Thu, Feb 05, 2015 at 10:53:06PM +0000, Margaret Lewicka wrote: > > > +/* Fixes for Mac OS X */ > > > +#if defined __APPLE__ && defined __MACH__ > > > +#include <sys/un.h> > > > +#endif > > > +#ifndef

On 9 February 2015 at 09:56, Pino Toscano <ptoscano@redhat.com> wrote: > On Friday 06 February 2015 10:03:37 Richard W.M. Jones wrote: [...] >> #if !(defined __APPLE__ && defined __MACH__) >> execlp ("fusermount", "fusermount", "-u", mountpoint, NULL); >> #else >> execlp ("/sbin/umount",

On 6 February 2015 at 10:03, Richard W.M. Jones <rjones@redhat.com> wrote: [...] > Linux doesn't have getprogname. One way around this is to add > getprogname to the list of functions in configure.ac AC_CHECK_FUNCS. > That will cause a macro to be defined which you can use like this: > > #if HAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME == 1 > # define program_name

...nline assembly in a way that's ultimately significantly harder for the compiler to support than a language feature, and now it's your problem." I agree with Chandler that we should just design and implement the language feature. > > I would recommend: > > if (__builtin_patchable_branch("section name")) { > trace(); > } > > ==> > > %0 = call i1 @llvm.patchable_branch(i8* @sectionNameString) > br %0, ... > > where @llvm.patchable_branch has the semantics of appending whatever patching information is necessary to the given...

Replace all the open-coded macros for generating calls with a pair of more general macros (__PVOP_CALL/VCALL), and redefine all the PVOP_V?CALL[0-4] in terms of them. [ Andrew, Andi: this should slot in immediately after "Document asm-i386/paravirt.h" (paravirt_ops-document-asm-i386-paravirth.patch) ] Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: Ingo Molnar

Replace all the open-coded macros for generating calls with a pair of more general macros (__PVOP_CALL/VCALL), and redefine all the PVOP_V?CALL[0-4] in terms of them. [ Andrew, Andi: this should slot in immediately after "Document asm-i386/paravirt.h" (paravirt_ops-document-asm-i386-paravirth.patch) ] Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: Ingo Molnar

...stopher wrote: > <snip conversation about call patching> It seems to me that there's a general feature here that LLVM is lacking, that would be useful in a number of JIT-compilation contexts, namely the ability to mark certain instructions (direct calls, perhaps branches too) as back-patchable. The thing that stands out to me is that back-patching a call or branch in a JIT'd program is very much like relocation resolution that a dynamic linker does at launch time for a statically compiled program. It seems like it might be possible to build on top of the runtime-dyld work that J...

On Thu, Feb 05, 2015 at 10:53:06PM +0000, Margaret Lewicka wrote: > Hello, > > I'm attempting to create a Homebrew formula to get libguestfs to > compile on Mac OS X. I've managed to achieve success with several > monkey patches, but since Homebrew's policy is to contact maintainers > about proper fixes in upstream, I would like to ask if there are any > plans to

...ch_template, x) / sizeof(void *)) - -#define paravirt_type(op) \ - [paravirt_typenum] "i" (PARAVIRT_PATCH(op)), \ - [paravirt_opptr] "i" (&(op)) -#define paravirt_clobber(clobber) \ - [paravirt_clobber] "i" (clobber) - -/* - * Generate some code, and mark it as patchable by the - * apply_paravirt() alternate instruction patcher. - */ -#define _paravirt_alt(insn_string, type, clobber) \ - "771:\n\t" insn_string "\n" "772:\n" \ - ".pushsection .parainstructions,\"a\"\n" \ - _ASM_ALIGN "\n" \ - _ASM_PTR...

On Friday 06 February 2015 10:03:37 Richard W.M. Jones wrote: > On Thu, Feb 05, 2015 at 10:53:06PM +0000, Margaret Lewicka wrote: > > Hello, > > > > I'm attempting to create a Homebrew formula to get libguestfs to > > compile on Mac OS X. I've managed to achieve success with several > > monkey patches, but since Homebrew's policy is to contact

...ificantly harder for > > the compiler to support than a language feature, and now it's your > > problem."  I agree with Chandler that we should just design and > > implement the language feature. > > > > I would recommend: > > > >   if (__builtin_patchable_branch("section name")) { > >     trace(); > >   } > > > > ==> > > > >   %0 = call i1 @llvm.patchable_branch(i8* @sectionNameString) > >   br %0, ... > > > > where @llvm.patchable_branch has the semantics of appending > >...

...follows: > 1) Offset at the end of the call instruction (offset of next instruction-1) if the call instruction occurs in code where GC can only take control at safe-points. As part of this change it would be great if LLVM could now guarantee that the call will be emitted at the end of the patchable space. It currently happens to emit at the beginning, but makes no guarantee. Emitting at the end works better for tracking the return address. > 2) Offset of the start of the call instruction if the call instruction occurs within a code-range that allows full interruption (that is, all i...

...es a lot of sense and is a really nice feature. However, I think implementing it with inline assembly imposes a lot of really unfortunate constraints on compilation -- it requires asm goto, pushsection and popsection, etc. > > I would much rather provide a much more direct way to represent a patchable nop and the addresses of label within a function. For example, I could imagine something like: > > ``` > if (0) { trace_call: /* code to call the trace function */ } > patch: __builtin_patchable_nop() > __builtin_save_labels(trace_call, patch) > ``` > > But someone...