similar to: 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

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

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

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

> 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

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,

TL;DR: At Google we use a call tracing system called XRay which inserts patchable instrumentation points into function entries and exits. If the community is interested, we'd like to contribute this system to the LLVM project. Many more details are contained in the whitepaper at: https://storage.googleapis.com/xray-downloads/whitepaper/XRayAFunctionCallTracingSystem.pdf Who's

Sanjoy, Joseph, and I will be hosting a BoF on using LLVM to build compilers for managed languages. We're curious to hear who's planning on attending and what topics you'd like to hear about. Depending on the expected audience, we're happy to do anything between a rough "what to expect getting started" to a down in the weeds working session on relevant optimization

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

Here is our proposal to extend/enhance the x86-64 compact unwind descriptors to fully describe the prologue/epilogue for asynchronous unwinding.  I believe there are missing/lacking CFI directives as well, but I'll save that for another thread. Asynchronous Compact Unwind Descriptors Ron Brender, VMS Software, Inc. Revised January 25, 2018 1  Introduction This document proposes means to

Hi Nick, It is a pleasure to be in contact with the creator of the compact unwind approach! I can see how an array of 32-bit unwind blocks could be used to describe each distinct point within a function (within a prolog in particular). But then you end up with six or seven or more such blocks for a large percentage of functions, don't you? Seems like a lot of additional space for something

> On 2015-Oct-12, at 10:41, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > > > Vedant Kumar wrote: >>>> That's a neat idea. To summarize: make Function have 3 optional operands. (For context -- Function currently has 1 optional operand, and my proposal is to move to 0.) >>>> >>>> Could someone else chime in on what

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]

John and Ron, I developed the original compact unwind implementation for macOS 10.6 back in 2009. I tried to leave space in the design to support finer grain exception handling such as for asynchronous or for the shrink wrap optimization. The idea I had at the time was instead of having just one 32-bit compact unwind info per function, there could be an array of them each covering a different

David Majnemer wrote: > > > On Mon, Oct 12, 2015 at 11:00 AM, Duncan P. N. Exon Smith via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > On 2015-Oct-12, at 10:41, Sanjoy Das > <sanjoy at playingwithpointers.com > <mailto:sanjoy at playingwithpointers.com>> 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 'hotpatch' attribute I just added.

I've done some measurements on this. The test program I have just calls Function::Create(), F->setPersonalityFn(), and then F->eraseFromParent() in a loop 2^20 times. Results: pre-patch --- min: 1.10s max: 1.13s avg: 1.11s post-patch --- min: 1.26s max: 1.35s avg: 1.29s So we expect to lose 0.2 seconds per 1 million functions (with personality functions) in a

Here is a WIP patch as promised: http://reviews.llvm.org/D13829 It uses a hungoff uselist to store optional data as needed. Some early objections from Duncan: - An extra one-time malloc() is required to set personality functions. - We get and set personality functions frequently. This patch introduces a level of indirection which slows the common case down. Is this overhead

>> That's a neat idea. To summarize: make Function have 3 optional operands. (For context -- Function currently has 1 optional operand, and my proposal is to move to 0.) >> >> Could someone else chime in on what they'd like to see? > > Sanjoy's idea makes sense to me, but only if we never need to add > prefix/prologue data after functions are created. Are