search for: molenda

...the content here: http://llvm.org/devmtg/2009-10/ FYI, one room recorded a screencast and the other was recorded with a standalone camera. This means that you can't see the speakers in one room, which is unfortunate but much better than no video :). I want to send a huge thanks to Jason Molenda. Not only did he contribute his equipment to record the event, he also collected a tremendous amount of the content, edited the videos, transcoded them and did a lot of other great work. Getting nice videos up takes a lot more work than it seems, and the video quality is very high this...

...nts (for compiling llvm) to python3 and dropping python2 support. In case of lit we probably need to keep the code in a way that works with python 2 and 3 though as that will affect various projects outside of core llvm that started adopting it. - Matthias > On Jan 29, 2018, at 3:42 PM, Jason Molenda via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Fangrui, for what it's worth regarding lldb, Zachary Turner has already done a lot of work to make the majority of its python code (most importantly, its testsuite) work with Python 3 as well as Python 2. > > J > &g...

When gdb is stopped in a function with no known start address, it has to make a guess about how to get the caller's rip. Either we assume that the saved rip is at rsp+8, or we assume that the saved rip is found via the rbp register. But it's a guess either way - gdb can't find the start of the function so it can't know which is the correct method. It would be nice if it could

Hi Fangrui, for what it's worth regarding lldb, Zachary Turner has already done a lot of work to make the majority of its python code (most importantly, its testsuite) work with Python 3 as well as Python 2. J > On Jan 29, 2018, at 12:46 PM, Fāng-ruì Sòng via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi LLVM-Devs, > > I noticed that many Python scripts under

I run some code in JIT on x86-64 architecture. Even though llvm::NoFramePointerElim is set to true, I still see weird stack in gdb, see below. 800b485a4 is the current rip register where gdb stopped. Then many others values aren't valid. Then there is value that looks ok again. Why gdb can't determine stack? Yuri -- stack -- #0 0x0000000800b485a4 in ?? () #1 0x000000000000005f in

Hi LLVM-Devs, I noticed that many Python scripts under utils/ have a shebang of `#!/usr/bin/python` (which is a symlink to python2.7 on many platforms) and some of them use Python 2 syntax that is not compatible with Python 3 (e.g. print statements; str/bytes) I created a revision to migrate utils/update_{llc_,}_test_checks.py from Python 2 to Python 3 https://reviews.llvm.org/D42450 , the

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

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

Not subscribed to the list, sorry to mess up the message threading - but to touch on one question that was raised earlier in the day, Bob Wilson wrote: > On Mar 28, 2014, at 4:23 PM, Jevin Sweval <jevinsweval at gmail.com> wrote: > >> Is the LLDB patch missing? I only see libc++, compiler-rt, LLVM, and Clang patches > > We have a patch for LLDB but it is combined with a