- User Since
- Apr 27 2019, 10:34 PM (82 w, 5 d)
Thu, Nov 19
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?
Mon, Nov 9
reverting because I'm not able to repro the fails, so need more time to figure it out.
Sun, Nov 8
Merged the 2 run/checks into one
Sun, Nov 1
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
Wed, Oct 28
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?
Jul 9 2020
This update still doesn't add windows support but I just want to get a feel that I'm going on the right direction.
It addresses the following:
Jun 16 2020
Thank you for this! <3
May 29 2020
Absolutely, I'll look into that first.
May 28 2020
thanks for the feedback, I'll read it more carefully later. As for the tests it should be easy to set up, didn't want to spend time on that before we agreed on doing it this way.
May 27 2020
I don't think we should ignore stderr this at this level, we should either do what Pavel suggests or send the stderr back through the protocol. I actually have some code that does this, it outputs both stderr and stdout to the console message. I did this because I want to be able to see in the vscode's debugger console what I see when running lldb in the command line and also because any text sent by lldb (e.g.: python interpreter) to the stdout will ruin the protocol communication. Let me put my code up in a diff.
May 19 2020
May 14 2020
Updated README.md, package.json to document the new option. Also refactored the test support a bit to allow easier testing.
@clayborg the support we added was for the lldb-server.
May 12 2020
I gotta say I don't understand the difference between "exit" and "terminate" commands, as both seem to happen pretty at once. Is the difference that "exit" commands are run only when the inferior exits freely on its own, and not when we forcefully kill it? And that "terminate" cmds are run in both cases?
May 11 2020
Rebase and remove unwanted debug code
I chose the name terminate because this happens just before the terminated event is sent back to the client.
Remove debugging leftovers
Mar 30 2020
Feb 28 2020
Jan 23 2020
Yeah, I'm not sure why the LoadModules function is calling target.SetExecutableModule. It is true that the libraries-svr4 will not include the main executable in its list.
This code was added in the context of providing qXfer:libraries support here: https://reviews.llvm.org/D9471. I don't see any mention of including the executable on that packet though: https://sourceware.org/gdb/current/onlinedocs/gdb/Library-List-Format.html. @clayborg was the main reviewer there (although this was 5 years ago or so) and he does mention multiple times in the comments this exact issue with calling target.SetExecutableModule. Maybe he can still remember and provide some light here :).
Dec 5 2019
Fair enough, I haven't seen evidence of this (haven't searched for it) but I imagine IDEs need to ignore this as well otherwise they just barf if they're expecting Content-Length and a wild print appears. The notion of stdout of SBDebugger is the SBCommandReturnObject which doesn't print right away (only when the command finishes executing) and from my previous tests .flush() doesn't help with this. I believe this is the reason why people opt to use print instead in their custom commands. But I don't think it's a reasonable assumption (or api contract) to tell people they can't use print or it breaks lldb-vscode.
Dec 3 2019
Maybe you could do something similar to LocalLLDBInit.test ?
That test uses the lldb -S (and others) flags that lldb-vscode doesn't support :(. These flags should really be added to the initialize packet but they're very specific to lldb and the DAP doesn't support it.. We could implement something like what Driver::ProcessArgs does and pass options through envs but, the logic in ProcessArgs itself is sketchy (just like the comment mentions) and I l also find it odd to pass options through env vars...
Dec 2 2019
Put the logic into a function