It was assuming that for any location M.N, N was always less than the number of breakpoint locations. But if you rebuild the target and rerun multiple times, when the section backing one of the locations is no longer valid, we remove the location, but we don't reuse the ID. So you can have a breakpoint that only has location 1.3. The num_locations check would say that was an invalid location.
Note that CommandArgumentEntry is an alias for: std::vector<CommandArgumentData>
…ror() [NFC]
To support detecting MD5 checksum mismatches, deal with SupportFiles rather than a plain FileSpecs in the SourceManager.
The majority of the replaced Target pointers were already used unconditionally and the few that were shouldn't even be NULL.
Currently, CommandObjects are obtaining a target in a variety of ways. Often the command incorrectly operates on the selected target. As an example, when a breakpoint command is running, the current target is passed into the command but the target that hit the breakpoint is not the selected target. In other places we use the CommandObject's execution context, which is frozen during the execution of the command, and comes with its own limitations. Finally, we often want to fall back to the dummy target if no real target is available. Instead of having to guess how to get the target, this patch introduces one helper function in CommandObject to get the most relevant target. In order of priority, that's the target from the command object's execution context, from the interpreter's execution context, the selected target or the dummy target. rdar://110846511
As a minor follow up for https://github.com/llvm/llvm-project/pull/97675, I'm renaming `SupportsExceptionBreakpoints` to `SupportsExceptionBreakpointsOnThrow` and adding a `SupportsExceptionBreakpointsOnCatch` to have a bit of more granularity.
CommandObjectBreakpoint has a harcoded list of languages for which exception breakpoints can be enabled. I'm making this a bit more generic so that my Mojo plugin can get this feature. Basically, I'm adding a new overridable method `Language::SupportsExceptionBreakpoints` that can be used by language plugins to determine whether they support this feature or not. This method is used in addition to the hardcoded list and, as an example, I'm using it for the ObjC language support. Another route is simply to avoid doing the check that it's being done right now and simply try to the create the exception breakpoint for whatever language that is not in the hardcoded list. I'm happy to do that if the reviewers think it's a good idea. As a note, the other possible place for adding this `SupportsExceptionBreakpoints` method is in `LanguageRuntime`. However, accessing it requires having a process, which is not always the case when invoking the `breakpoint set -E` command. The process might not be alive yet, so `Language` is a good second place for this. And as a final note, I don't want to make this `SupportsExceptionBreakpoints` complicated. I'm keeping it as simple as possible because it can easily evolve as it's not part of the public API.
This is another step towards supporting DWARF5 checksums and inline source code in LLDB. This is a reland of #85468 but without the functional change of storing the support file from the line table (yet).
Reverts llvm/llvm-project#85468 because @slackito reports this broke stepping in one of their tests [1] and this patch was meant to be NFC. [1] https://github.com/llvm/llvm-project/commit/d5a277d309e92b1d3e493da6036cffdf815105b1#commitcomment-139991120