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.

Checks the module is not loaded right after we attach

Removed unnecessary comment

Add test

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

We should have a test for this.

can you share the profiles you got? I'm curious on the speed up as I also with large c++ binaries.

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?

reverting because I'm not able to repro the fails, so need more time to figure it out.

Merged the 2 run/checks into one

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

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

Check all child sections and makes sure the section is an actual code section.

Should I still go ahead with this since @labath implemented the memory allocation on lldb-server?

Addressed all comments:

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!

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

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?

Make sure there's an empty abbrev table as the last table.

@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!

Check lowest code address instead of checking if the section is code.

Address comments

Moved the increment to the outer loop and used the already existing debug_info test instead of creating a new one.

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.

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