search for: hotpatchability

[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, 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...

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

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,

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...

> 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

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

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

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

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

>> 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

>> 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

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:

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

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

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 >

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]

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

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.

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