search for: hotpatchability

Displaying 20 results from an estimated 48 matches for "hotpatchability".

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"="hotpatch-compact" then: 1. The first instruction
2010 Oct 26
2
[LLVMdev] Implementing the hotpatch attribute for X86
Hi, According to http://blogs.msdn.com/b/freik/archive/2006/03/07/x64-hotpatchability.aspx, 'hotpatchable' functions on x86 (and by extension, x86-64) are preceded by six bytes of padding and start with a two byte instruction. The problem is that, still being relatively unfamiliar with the x86 backend, I have no idea how to implement this for the 'hotpatch' attribute...
2010 Oct 26
2
[LLVMdev] Implementing the hotpatch attribute for X86
On 10/26/10 5:24 PM, Michael Spencer wrote: > The linker adds the padding. Also, the first instruction just has to > be two bytes or longer. Not exactly two bytes. How then does the linker know to add the padding? I assume there's a PE-COFF attribute that will do that, but what about other file formats, like ELF or Mach-O? Bear in mind that I'm doing this for the Wine project, so
2010 Oct 26
0
[LLVMdev] Implementing the hotpatch attribute for X86
On Tue, Oct 26, 2010 at 7:27 PM, Charles Davis <cdavis at mymail.mines.edu> wrote: > On 10/26/10 5:24 PM, Michael Spencer wrote: >> The linker adds the padding. Also, the first instruction just has to >> be two bytes or longer. Not exactly two bytes. > How then does the linker know to add the padding? I assume there's a > PE-COFF attribute that will do that, Nope,
2010 Oct 26
0
[LLVMdev] Implementing the hotpatch attribute for X86
On Tue, Oct 26, 2010 at 7:02 PM, Charles Davis <cdavis at mymail.mines.edu> wrote: > Hi, > > According to > http://blogs.msdn.com/b/freik/archive/2006/03/07/x64-hotpatchability.aspx, > 'hotpatchable' functions on x86 (and by extension, x86-64) are preceded > by six bytes of padding and start with a two byte instruction. The > problem is that, still being relatively unfamiliar with the x86 backend, > I have no idea how to implement this for the 'hot...
2010 Oct 27
1
[LLVMdev] Implementing the hotpatch attribute for X86
> I don't know how GCC handles this case. They may do the padding in the > compiler. You are going to have to look at exactly what GCC does and > whatever hotpatch loader Wine uses to figure out what to do, but it > will most likely be incompatible with the Windows implementation. Why? I don't see how this might be incompatible with what MS linker does; in any case the end
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
2011 Sep 30
0
[LLVMdev] [patch] Add the returns_twice attribute
While I'd like to see support for hotpatching, the other Clang bugs block it from being useful. If Mozilla is close to working, let them have it. Thanks for asking :). -Austin On Thu, Sep 29, 2011 at 21:39, Charles Davis <cdavis at mymail.mines.edu> wrote: > Howdy Austin, > > I'm about to sacrifice the Hotpatch attribute (which I added a long time ago to start fixing
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
2012 Jun 15
0
Wine release 1.4.1
The Wine maintenance release 1.4.1 is now available. What's new in this release (see below for details): - Translation updates. - Various bug fixes. The source is available from the following locations: http://prdownloads.sourceforge.net/wine/wine-1.4.1.tar.bz2 http://mirrors.ibiblio.org/wine/source/1.4/wine-1.4.1.tar.bz2 Binary packages for various distributions will be available
2014 Jan 03
2
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
>> On Thu, 2014-01-02 at 16:56 -0800, Eric Dumazet wrote: >> >> Hmm... it looks like I missed __GFP_NORETRY >> >> >> >> diff --git a/net/core/sock.c b/net/core/sock.c >> index 5393b4b719d7..5f42a4d70cb2 100644 >> --- a/net/core/sock.c >> +++ b/net/core/sock.c >> @@ -1872,7 +1872,7 @@ bool skb_page_frag_refill(unsigned int sz, struct
2014 Jan 03
2
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
>> On Thu, 2014-01-02 at 16:56 -0800, Eric Dumazet wrote: >> >> Hmm... it looks like I missed __GFP_NORETRY >> >> >> >> diff --git a/net/core/sock.c b/net/core/sock.c >> index 5393b4b719d7..5f42a4d70cb2 100644 >> --- a/net/core/sock.c >> +++ b/net/core/sock.c >> @@ -1872,7 +1872,7 @@ bool skb_page_frag_refill(unsigned int sz, struct
2012 Mar 16
0
Wine release 1.5.0
The Wine development release 1.5.0 is now available. What's new in this release (see below for details): - New version of the Gecko engine. - Partial support for using the Trash on Mac OS X. - Support for path gradients in GdiPlus. - Various MSXML improvements. - Fixes to 64-bit exception handling. - Various bug fixes. The source is available from the following locations:
2015 Jan 23
0
Wine release 1.7.35
The Wine development release 1.7.35 is now available. What's new in this release (see below for details): - Beginnings of support for OpenGL core contexts. - Initial support for glyph placement in DirectWrite. - Some more WBEM objects. - Various bug fixes. The source is available from the following locations: http://prdownloads.sourceforge.net/wine/wine-1.7.35.tar.bz2
2011 Sep 27
1
[LLVMdev] Function attribute size limit
Hi everyone, It looks to me like we're out of bits for function attributes. I need another one, unfortunately... Is there any objection to moving to 64 bits? I can write the patch. Thanks, Patrick
2014 Jan 03
0
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
On Fri, 2014-01-03 at 17:47 -0500, Debabrata Banerjee wrote: > >> On Thu, 2014-01-02 at 16:56 -0800, Eric Dumazet wrote: > >> > >> Hmm... it looks like I missed __GFP_NORETRY > >> > >> > >> > >> diff --git a/net/core/sock.c b/net/core/sock.c > >> index 5393b4b719d7..5f42a4d70cb2 100644 > >> --- a/net/core/sock.c >
2014 May 27
6
[LLVMdev] [PATCH] Symbol offsets
Somehow this cover letter was dropped from my symbol offsets patch set: 1. http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073200.html 2. http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073201.html Original message ----------------- About a year ago a proposal suggesting symbol offsets was brought to this list[1]. This proposal goes hand-in-hand with the prefix data proposal[2]
2011 Feb 23
1
[LLVMdev] LLVM ExecutionEngine/JIT trampoline question
I understand that we need to push the address to a register then branch using the register. But i am asking why there is a trampoline there such that a call to foo is first branched to an snippet and the snippet branches to the X86CompilationCallback. is this snippet necessary ? Thanks Xin On Tue, Feb 22, 2011 at 12:39 PM, Reid Kleckner <reid.kleckner at gmail.com>wrote: > The
2015 Oct 16
0
Wine release 1.7.53
The Wine development release 1.7.53 is now available. What's new in this release (see below for details): - Support for the various versions of XAudio. - More implementation of the Web Services DLL. - Improved OLE object embedding. - Various code cleanups in Direct3D. - New MAINTAINERS file and Signed-off-by requirement to improve the patch review process. - Various bug fixes.
2014 Jan 03
2
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
On Thu, 2014-01-02 at 16:56 -0800, Eric Dumazet wrote: > > My suggestion is to use a recent kernel, and/or eventually backport the > mm fixes if any. > > order-3 allocations should not reclaim 2GB out of 8GB. > > There is a reason PAGE_ALLOC_COSTLY_ORDER exists and is 3 Hmm... it looks like I missed __GFP_NORETRY diff --git a/net/core/sock.c b/net/core/sock.c index