- User Since
- Jun 2 2015, 7:30 PM (220 w, 4 d)
Wed, Aug 7
Tue, Aug 6
LGTM. Probably good to have someone else weigh in before committing (I touched this code last, but only to fix a couple bugs).
Fri, Aug 2
- Expand comment about return trampolines
- rename PropagateTrapHandlerFlag -> PropagateTrapHandlerFlagFromUnwindPlan
Wed, Jul 31
- add test
- Move resolution helper from RegisterContextLLDB to lldb_private::Address
- Defensively initialize out arguments
Tue, Jul 30
#include <signal.h> #include <stdio.h> #include <stdlib.h>
Jul 21 2019
Jul 19 2019
Jul 18 2019
Jul 15 2019
I'm guessing on this Linux system, you've got a trap receiver function on the stack that is on its first instruction or something? So backing up the pc value for *that* frame is the problem you're solving.
Just just to check, we've got a backtrace like...
ping @jasonmolenda -- do the updates look like what you had in mind when you said " It'd be a good change to capture that information from the eh_frame though, even if we don't see a clear way to use it right now"?
That LLDB frame #5 is a bit bogus
Jun 27 2019
- Include __restore_rt
Jun 25 2019
- fix copy pasta
I've updated this with code to recognize the 'S' in the eh_frame augmentation and record it in a new bool member of UnwindPlan, m_plan_is_for_signal_trap. I haven't hooked up any consumers of the new bit; as you say, with the current code flow we don't parse the eh_frame info until after we've decided whether the current frame is a trap handler frame or not.
- Fix typos
- Convey 'S' eh_frame augmentation to UnwindPlan
Jun 21 2019
FYI, I sent mail about this to lldb-dev.. I'll copy the contents here for the benefit of anybody who didn't see it there but could use the context:
Jun 17 2019
Jun 14 2019
Jun 13 2019
Jun 11 2019
- Remove useless assignment
- Add -earlycse-debug-hash flag, shorten new test
Jun 6 2019
Jun 5 2019
Fix style, rebase on top of test change
May 29 2019
Apr 24 2019
Switched to static function, and yes I do have commit access. Thanks for the review!
- Use static function rather than anonymous namespace
Apr 23 2019
@labath, as discussed in D59991, I went with a local copy of the function since I didn't see an obvious opportunity to tweak the calling code, but maybe I overlooked something. My copy of cpuid.h matches https://github.com/gcc-mirror/gcc/blob/gcc-5-branch/gcc/config/i386/cpuid.h
Apr 4 2019
Thanks for the review!
Apr 3 2019
- Merge exe yaml with test file, remove more cruft
- Address review feedback
Names normalized, cruft removed, thanks for the feedback.
No, I hadn't seen the test files in lld/test/COFF; thanks for the pointers! Testcase added; I verified that it fails without the fix and passes without it, and that neither make check nor make check-lld regress.
- add testcase
Apr 2 2019
Apr 1 2019
I'm not sure how to update the tests for this change. Ideally I'd change test/tools/llvm-readobj/imports.test to use an input that has multiple delay-load DLL references. The inputs for that are (binary) coff files test/tools/llvm-readobj/Inputs/imports.exe.coff-x86-64 and test/tools/llvm-readobj/Inputs/imports.exe.coff-i386. @ruiu , do we have sources for those binaries checked in or otherwise available somewhere? Should I just generate new ones with similar import lists?
Nov 29 2018
Nov 28 2018
Nov 21 2018
Oct 25 2018
I don't see this or its unsigned counterpart added to the LangRef; is that intentional, or an oversight?
Jun 14 2018
Nov 3 2016
Sep 3 2016
Sep 2 2016
- Add assertions guarding against over-propagation of unwind dest token
Sep 1 2016
- fix typo
- fix bogus assertion, add testcase covering it
Aug 31 2016
Feb 23 2016
HandleInlinedEHPad builds up the FuncletUnwindMap looking at the pre-inlining callee IR. Sharing it with the new call to getUnwindDestToken might be benign, but I'm not sure. I think it would be safer to use a separate FuncletUnwindMap for the new call. Probably also safer to compute the unwind dest in the caller before the code on line 1759 has had a chance to give the caller EH pad new uses in the partially-rewritten inlinee which might confuse the computation.
Feb 4 2016
FYI, I've split this out into constituent changes (locally). I think at this point it makes sense to hold off uploading them individually to Phabricator until they're ready for real review (for fear I'd lose track of things otherwise), but I do have them pushed up to my GitHub fork for my own sake, so if someone happens to want to look at the changes that way, they are:
Feb 3 2016
Feb 2 2016
I went to create the spill slots up-front. Looking at the code after doing that, I realized it makes it more readable to pull all of the spill/fill insertion into the new pass, so that its workings are akin to the rematerialization pass. So I did that.