Current state in scripted process expects [all the
modules](https://github.com/llvm/llvm-project/blob/912b154f3a3f8c3cebf5cc5731fd8b0749762da5/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp#L498)
passed into "get_loaded_images" to load successfully else none of them
load. Even if a module loads fine, [but has already been
appended](https://github.com/llvm/llvm-project/blob/912b154f3a3f8c3cebf5cc5731fd8b0749762da5/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp#L495)
it still fails. This is restrictive and does not help our usecase.

**Usecase**: We have a parent scripted process using coredump +
tombstone.

1) Scripted process uses child elf-core process to read memory dump

2) Uses tombstones to pass thread names and modules.

We do not know whether the modules will be successfully downloaded
before creating the scripted process. We use [python module
callbacks](https://github.com/llvm/llvm-project/blob/a57e58dbfaae0e86eb5cafeddf8b598f14b96e36/lldb/source/Target/Platform.cpp#L1593)
to download a module from symbol server at LLDB load time when the
scripted process is being created. The issue is that if one of the
symbol is not found from the list specified in tombstone, none of the
modules load in scripted process. Even if we ensure symbols are present
in symbol server before creating the scripted process, if the load
address is wrong or if the module is already appended, all module loads
are skipped.

**Solution**: Pass in a custom boolean option arg for every module from
python scripted process plugin which will indicate whether to ignore the
module load error. This will provide the flexibility to user for loading
the successfully fetched modules into target while ignoring the failed
ones

---------

Co-authored-by: rchamala <rachamal@fb.com>

When a test depends on a new debugserver feature/fix, the API test must
be marked @skipIfOutOfTreeDebugserver because the macOS CI bots test
using the latest Xcode release debugserver. But over time all of these
fixes & new features are picked up in the Xcode debugserver and these
skips can be removed.

We may see unexpected test failures from removing all of these 1+ year
old skips, but that's likely a separate reason the test is failing that
is being papered over by this skip.

This patch disables TestStackCoreScriptedProcess.py since it times out
non deterministicly.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

This patch should address the failure of TestStackCoreScriptedProcess
that is happening specifically on x86_64.

It turns out that in 1370a1cb5b97, I changed the way we extract integers
from a `StructuredData::Dictionary` and in order to get a stop info from
the scripted process, we call a method that returns a `SBStructuredData`
containing the stop reason data.

TestStackCoreScriptedProcess` was failing specifically on x86_64 because
the stop info dictionary contains the signal number, that the `Scripted
Thread` was trying to extract as a signed integer where it was actually
parsed as an unsigned integer. That caused `GetValueForKeyAsInteger` to
return the default value parameter, `LLDB_INVALID_SIGNAL_NUMBER`.

This patch address the issue by extracting the signal number with the
appropriate type and re-enables the test.

Differential Revision: https://reviews.llvm.org/D152848

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

This reverts commit 4177b490358432a457935ba5d6d076ae60de588f, since I
landed it by mistake.

This patch should address the failure of TestStackCoreScriptedProcess
that is happening specifically on x86_64.

It turns out that in 1370a1cb5b97, I changed the way we extract integers
from a `StructuredData::Dictionary` and in order to get a stop info from
the scripted process, we call a method that returns a `SBStructuredData`
containing the stop reason data.

TestStackCoreScriptedProcess` was failing specifically on x86_64 because
the stop info dictionary contains the signal number, that the `Scripted
Thread` was trying to extract as a signed integer where it was actually
parsed as an unsigned integer. That caused `GetValueForKeyAsInteger` to
return the default value parameter, `LLDB_INVALID_SIGNAL_NUMBER`.

This patch address the issue by extracting the signal number with the
appropriate type and re-enables the test.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

The x86_64 macOS CI bot is failing because this test
times out.  It was marked as expectedFail earlier today,
but that's not considered a fail so the CI runs are
red.  Skipping it on Darwin for now until Ismail can
look into it.

This reverts commit 429e74839506ea8ba962d24647264ed81f680bbf since it
didn't address the test failures on GreenDragon.

This patch will mark the tests as expected to fail until I can reproduce
the issue and find a solution.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).

If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.

RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Differential revision: https://reviews.llvm.org/D151460

This patch skips TestStackCoreScriptedProcess because the test times out
when the Address Sanitizer is running.

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>