- User Since
- Apr 27 2019, 10:34 PM (142 w, 1 d)
Feb 21 2021
oh no, I picked the wrong commit to land :(. I think this is fine because I already addressed the comments, but if there's still something I should work on here, I'll put another diff up.
Feb 20 2021
Checks the module is not loaded right after we attach
Feb 19 2021
Removed unnecessary comment
Feb 18 2021
I don't think this does what you think it does. The $() doesn't give you the process id of anything -- it substitutes a string by the result of running that string as a shell command. So, the PID variable would get the (entire) stdout of %s.out
Add api test
revert last amend: added the test to the wrong diff
Add api test
Feb 16 2021
We should have a test for this.
Feb 14 2021
Feb 12 2021
can you share the profiles you got? I'm curious on the speed up as I also with large c++ binaries.
Jan 20 2021
Jan 19 2021
Nov 19 2020
When I landed this I got test errors on the windows machine (the same tests pass on the other machine). I tried to repro this on 2 different machines I was able to get access but to no avail.
These are the failing tests: http://lab.llvm.org:8011/#/builders/83/builds/644 but when I ran lldb-test on the find-basic-function the output was what I would expect so not really sure how I can figure this out. Any ideas?
Nov 9 2020
reverting because I'm not able to repro the fails, so need more time to figure it out.
Nov 8 2020
Merged the 2 run/checks into one
Nov 1 2020
Use set and rebase
Also set the symbol as external when it is weak
Address all comments (I hope)
Used -s to feed commands and disabled errors when interpreting them
Oct 28 2020
Rewrote the test in lit.
- Fixed formatting issues
- Updated comment on the reason we need to do this
- Improved the lit test by also checking how many matches it found
Oct 22 2020
Check all child sections and makes sure the section is an actual code section.
Oct 19 2020
Oct 18 2020
Should I still go ahead with this since @labath implemented the memory allocation on lldb-server?
Addressed all comments:
Oct 6 2020
Oct 5 2020
I explored Greg's suggestion of checking if the functions were external symbols. As suspected the overriden mmap is not external, so we can use this check to avoid calling it!
Sep 21 2020
It seems like calling any 'mmap' definition should work. Is the interposed mmap implementation failing and correctly returning -1, or is it succeeding and incorrectly returning -1? In either case, it seems like it's worth digging into why it's failing / returning the wrong result
Sep 20 2020
Why would we be doing something (particularly a thing which will be hard to do in a cross-platform manner, and will very likely border on, or downright cross into, undefined behavior territory), if we get that from vscode for free?
Sep 17 2020
Sep 14 2020
Sep 13 2020
Make sure there's an empty abbrev table as the last table.
Sep 12 2020
@Higuoxing I didn't realize the DWARF section was completely new until I read your GSOC project. Thanks a lot for this work otherwise it would have been impossible for me to create the tests I needed for my other diff!
Sep 5 2020
Check lowest code address instead of checking if the section is code.
Moved the increment to the outer loop and used the already existing debug_info test instead of creating a new one.
Sep 4 2020
Aug 24 2020
Aug 22 2020
Update to create 2 separate install targets
Sounds good, will update. In my mind it would be easier to just install all configured python scripts by specifying a single distribution component.
Aug 21 2020
After reading a bit more how clang-tidy works this isn't fixable because it actually needs to compile it. I also didn't find a way to exclude a file from it.
My plan is to just land this and then make a PR to add this file to https://github.com/google/llvm-premerge-checks/blob/master/scripts/clang-tidy.ignore
Moved the header file to be in Plugins/ScriptInterpreter/Python so clang-tidy doesn't get confused solving include paths.
Added include guards, clang-format and python include
Updated to use more friendly component name lldb-python-scripts name instead of finish_swig_python_scripts
Aug 19 2020
@JDevlieghere thanks for the quick review, but on the name I mean the actual finish_swig_python_scripts, this sounds like a step name and not a component distributed by llvm like liblldb ot lldb-server. That was the reason at the time I named it lldb-python-scripts because it was very clear what was being installed.
Would you be fine with me changing swig_scripts_target back to lldb-python-scripts?