search for: patchability

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

[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"="hotpatch-compact" then: 1. The first instruction

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

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

> On Apr 4, 2017, at 11:44 AM, John McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> On Apr 4, 2017, at 2:12 PM, Matthias Braun <matze at braunis.de <mailto:matze at braunis.de>> wrote: >> My two cents: >> >> - I think inline assembly should work even if the compiler cannot parse the contents. This would rule out msvc inline assembly

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

On Apr 3, 2011, at 12:11 PM, Eric Christopher 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

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

Make paravirt_types.h more understandable: - Use more consistent and logical naming - Simplify interfaces - Put related macros together - Improve whitespace Signed-off-by: Josh Poimboeuf <jpoimboe at redhat.com> --- arch/x86/include/asm/paravirt_types.h | 104 ++++++++++++++++++---------------- 1 file changed, 54 insertions(+), 50 deletions(-) diff --git

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

FYI there is now serious talk of the Linux kernel dropping support for compilers that *don't* support asm goto. On Tue, 2017-04-04 at 13:13 -0700, Matthias Braun via llvm-dev wrote: > > > On Apr 4, 2017, at 11:44 AM, John McCall via llvm-dev > > ts.llvm.org> wrote: > > > > > On Apr 4, 2017, at 2:12 PM, Matthias Braun <matze at braunis.de> > >

> On Jul 9, 2015, at 3:33 PM, Swaroop Sridhar <Swaroop.Sridhar at microsoft.com> wrote: > > Regarding Call-site size specification: > > CoreCLR (https://github.com/dotnet/coreclr <https://github.com/dotnet/coreclr>) requires the size of the Call-instruction to be reported in the GCInfo encoding. > > The runtime performs querries for StackMap records using

My two cents: - I think inline assembly should work even if the compiler cannot parse the contents. This would rule out msvc inline assembly (or alternatively put all the parsing and interpretation burden on the frontend), but would work with gcc asm goto which specifies possible targets separately. - Supporting control flow in inline assembly by allowing jumps out of an assembly block seems