search for: hotpatched

[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 I just added.

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

> 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

...ng 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 instrumentation at runtime. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160414/a061e542/attachment.html>

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

...logical compact/reclaim behavior but doesn't fix it. Actually it still really quite bad because the whole thing loops until it gets to order-0 so it's effectively trying the allocation 4 times anyway. I typically see non-zero order allocations very rarely without these two pieces of code. I hotpatched a running system to get results from this quickly. Even setting the max order to order-1 I still see bad behavior. If anything this behavior should be conditional until this is ironed out. Performance data: http://pastebin.ubuntu.com/6687527/ -Debabrata

...logical compact/reclaim behavior but doesn't fix it. Actually it still really quite bad because the whole thing loops until it gets to order-0 so it's effectively trying the allocation 4 times anyway. I typically see non-zero order allocations very rarely without these two pieces of code. I hotpatched a running system to get results from this quickly. Even setting the max order to order-1 I still see bad behavior. If anything this behavior should be conditional until this is ironed out. Performance data: http://pastebin.ubuntu.com/6687527/ -Debabrata

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

...aim behavior but > doesn't fix it. Actually it still really quite bad because the whole > thing loops until it gets to order-0 so it's effectively trying the > allocation 4 times anyway. I typically see non-zero order allocations > very rarely without these two pieces of code. I hotpatched a running > system to get results from this quickly. Even setting the max order to > order-1 I still see bad behavior. If anything this behavior should be > conditional until this is ironed out. > > Performance data: http://pastebin.ubuntu.com/6687527/ It seems that you shoot the m...

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