similar to: [RFC] Improving compact x86-64 compact unwind descriptors

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

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

Hi John & Ron, I read through the proposal and had a couple of quick observations. 1. The proposed encoding assumes that the epilogue instructions always come at the end of the function -- or rather, just before the next function. If there is a stack protector __stack_chk_fail sequence, or there is NOP padding between functions, then the epilogue cannot be expressed. The proposed encoding

Hi all, We're at the point in our port of OpenVMS to x86-64 that we're working on the unwind code.  The current ABI and the current codebase doesn't have enough support for true asynchronous unwinding from any point (most notably in the prologue/epilogue) in the code that OpenVMS needs.  We're working on a set of changes to the compact unwind information to handle the additional

> Message: 3 > Date: Sun, 3 Jul 2016 17:49:50 -0700 > From: Michael Lewis via llvm-dev <llvm-dev at lists.llvm.org> > To: Hayden Livingston <halivingston at gmail.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] Status of stack walking in LLVM on Win64? > Message-ID: > <CAEm7p3svyOi6JU6r_RCCtRfGhTgTHeRw-SR0iD+9Edv2pi71Dw at

 > These is metadata for epilogues (UWOP_EPILOG) but it is only available on Windows 8.1 and newer. I'm aware of this. I believe it is so sampling profilers can walk the kernel stack including through paged code -- i.e. the epilogue data is not paged, while the related epilogue code might be. Do you see it used, i.e. in usermode?  (where the pdata/xdata/code are all equally paged). It

On Fri, Sep 18, 2009 at 11:13:52AM -0700, Nick Kledzik wrote: > > The important thing is that only one unwinder is used. The > _Unwind_Context data structure is different between the darwin and FSF > implementations, so you can't pass it between two different > implementations. Since darwin uses two-level namespace and swapping in > a new libgcc_s.dylib at runtime

I think it's valuable to have precise / asynchronous unwind information without adding support for non-call exceptions. Profilers and debuggers need to be able to unwind the stack from arbitrary instruction boundaries, but they don't need to run exception handlers. We can still declare that outside the model. Speaking of which, barring bugs, we do support precise unwind info on Win64.

> From: Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> > Emitting directives in the epilogue is hard because the directives > apply to all instructions after in program-counter order. So if you > have an epilogue in the middle of a function and emit CFI directives > saying the registers are back where they were then the unwinder will > think that applies to the

Hi Rafael, I've been staring at the CFI directives and have a question. Some background: I want to generate the compact unwind information using just the CFI directives. I *think* that this should be doable. The issue I'm facing right now is that I need to know how much the stack pointer was adjusted. So when I have something like this: .cfi_startproc Lfunc_begin175:

On 19 Jan 2018, at 14:48, John Reagan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > OpenVMS' EH model is for full asynchronous prologue/epilogue EH. We do more > than just program-level EH, but have to deal with OS events (timers going off, > asynch I/O completion, mailboxes filled with data, etc.) which could result in > an unwind occurring. > >

I dug into this. Based on the .s files in bugzilla, the latest gcc is now adding dwarf unwind info to describe the function epilog. If you run dwarfdump --eh-frame on the .o files made with the new compiler, you'll see extra dwarf unwind instructions at the end like: ... DW_CFA_advance_loc4 (64) #<-- advance to near end of function

On Aug 3, 2010, at 3:04 PM, Cameron Esfahani wrote: > I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: > > _main: > pushq %rbp > Ltmp18: > movq %rsp, %rbp > Ltmp19: > subq $320, %rsp > Ltmp20: > movl %ecx, -276(%rbp) > > I've tracked them back to emitPrologue in

On 5 September 2013 19:27, Bill Wendling <wendling at apple.com> wrote: > Hi Rafael, > > I've been staring at the CFI directives and have a question. Some background: I want to generate the compact unwind information using just the CFI directives. I *think* that this should be doable. The issue I'm facing right now is that I need to know how much the stack pointer was

Hi Francis, Thanks for getting back to me. Could you please provide more details about the problems you encounter with those tools and what improvements required to improve compact unwinding format? Most of my experience is in the mid end, but it is still surprising to me that an improved shrink wrap will break that many tools, considering the fact that gcc has a good shrink wrapping pass and

--- include/share/alloc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/share/alloc.h b/include/share/alloc.h index 914de9ba..63878db0 100644 --- a/include/share/alloc.h +++ b/include/share/alloc.h @@ -168,7 +168,7 @@ static inline void *safe_realloc_add_2op_(void *ptr, size_t size1, size_t size2) free(ptr); return 0; } - return realloc(ptr, size2); + return

I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: _main: pushq %rbp Ltmp18: movq %rsp, %rbp Ltmp19: subq $320, %rsp Ltmp20: movl %ecx, -276(%rbp) I've tracked them back to emitPrologue in X86RegisterInfo.cpp. I'm wonder what's their purpose? They're filling up my symbol table... Cameron Esfahani

[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

Dear R experts, I am trying to arrange multiple plots, creating one graph for each size1 factor variable in my data frame, and each plot has the median price on the y-axis and the size2 on the x-axis grouped by clarity: library(ggplot2) df <- data.frame(price=matrix(sample(1:1000, 100, replace = TRUE), ncol = 1)) df$size1 = 1:nrow(df) df$size1 = cut(df$size1, breaks=11)

On Aug 3, 2010, at 3:12 PM, Eric Christopher wrote: > > On Aug 3, 2010, at 3:04 PM, Cameron Esfahani wrote: > >> I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: >> >> _main: >> pushq %rbp >> Ltmp18: >> movq %rsp, %rbp >> Ltmp19: >> subq $320, %rsp >>