search for: patchabl

Displaying 20 results from an estimated 93 matches for "patchabl".

Did you mean: patchable
2016 Apr 06
2
RFC: New function attribute "patchable-prologue"="<kind>"
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
2016 Apr 14
3
RFC: New function attribute "patchable-prologue"="<kind>"
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...
2016 Apr 06
7
RFC: New function attribute "patchable-prologue"="<kind>"
[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...
2016 Apr 07
2
RFC: New function attribute "patchable-prologue"="<kind>"
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...
2016 Apr 14
2
RFC: New function attribute "patchable-prologue"="<kind>"
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
2001 Nov 05
1
Kernel 2.4.3 & ext3 patchable?
-----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!
2015 Feb 06
0
Re: Patchable build problems on OS X 10.10
[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
2015 Feb 07
1
Re: Patchable build problems on OS X 10.10
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
2015 Feb 09
0
Re: Patchable build problems on OS X 10.10
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 > >
2015 Feb 09
0
Re: Patchable build problems on OS X 10.10
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",
2017 Apr 04
3
[inline-asm][asm-goto] Supporting "asm goto" in inline assembly
...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...
2007 Apr 18
0
[PATCH] paravirt_ops: Clean up paravirt patchable wrappers
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
2007 Apr 18
0
[PATCH] paravirt_ops: Clean up paravirt patchable wrappers
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
2011 Apr 04
1
[LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
...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...
2015 Feb 06
0
Re: Patchable build problems on OS X 10.10
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
2017 Oct 04
0
[PATCH 08/13] x86/paravirt: Clean up paravirt_types.h
...ate, 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...
2015 Feb 09
5
Re: Patchable build problems on OS X 10.10
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
2018 Feb 12
0
[inline-asm][asm-goto] Supporting "asm goto" in inline assembly
...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 > >...
2015 Jul 09
5
[LLVMdev] [RFC] New StackMap format proposal (StackMap v2)
...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...
2017 Apr 04
4
[inline-asm][asm-goto] Supporting "asm goto" in inline assembly
...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...