- User Since
- Jun 2 2015, 7:30 PM (236 w, 4 d)
Wed, Dec 4
Tue, Dec 3
- Use invalid_argument error code
- Change signature to return Expected<vector<BreakpointSP>>
Mon, Dec 2
Oct 18 2019
Oct 17 2019
- Use Twine instead of formatv
Oct 16 2019
Oct 15 2019
- punctuation fixes
Oct 14 2019
- Move test
- Remove TODO, lit-ify negative test and tighten check
Oct 13 2019
- ...and fix namespace...
- Fix Expected<> types
- Apply review feedback (-auto, -memset, +comments)
Oct 11 2019
Just to make sure I'm understanding the feedback correctly, I'll try to summarize. Please let me know if this is off track:
Added Exception stream to minidump-basic.yaml as suggested.
Address review feedback
- Remove useless comment and leftover debugging cruft
Oct 10 2019
- Update test input yaml Exception stream
- Add testcase
- Add test with extraneous parameter
- Change Exception Information format per feedback
- Define DumpRequested constant in-line, per feedback in D68656
- Remove ExceptionCode enumeration
Oct 9 2019
- Remove the os-defined exception code enum values
Oct 8 2019
Nit: Title says "thread" rather than "memory info"
Sep 30 2019
- Review feedback
Sep 27 2019
- Use accessor for m_unix_signals_sp
- Move artificial SIGSTOP injection to RefreshStateAfterStop
Fortunately, for the functionality you're testing, I don't think you really need the executable file, so you can just ignore the elf bit and test with a plain lldb -c foo.dmp (obviously, you won't get the backtrace that way, but you don't really need that here.
Sep 26 2019
I'm trying to fix an issue where opening a minidump created by breakpad in lldb just hangs, but if I use breakpad's minidump-2-core on that same dump then opening the core dump works fine. From debugging the two cases I can see that the critical logic that ProcessElfCore has which ProcessMinidump lacks is here, and the code in this patch is my attempt to replicate that.
Aug 7 2019
Aug 6 2019
LGTM. Probably good to have someone else weigh in before committing (I touched this code last, but only to fix a couple bugs).
Aug 2 2019
- Expand comment about return trampolines
- rename PropagateTrapHandlerFlag -> PropagateTrapHandlerFlagFromUnwindPlan
Jul 31 2019
- add test
- Move resolution helper from RegisterContextLLDB to lldb_private::Address
- Defensively initialize out arguments
Jul 30 2019
#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: