Not that we ever do that, because this is unused code, but if someone
was debugging lldb I guess they'd call this.

Was missed in https://github.com/llvm/llvm-project/pull/145645

Relates to https://github.com/llvm/llvm-project/issues/135208

Follow-up to
https://github.com/llvm/llvm-project/pull/145645#discussion_r2174948997

There's no need for this variable to be declared at the function-level.
We reset it in all the cases where it's used anyway.

This patch just inlines the usage of the variable entirely.

unbreak gcc CI bots.

This patch fixes:

  lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:415:7:
  error: label at end of compound statement is a C++23 extension
  [-Werror,-Wc++23-extensions]

  lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:536:7:
  error: label at end of compound statement is a C++23 extension
  [-Werror,-Wc++23-extensions]

  lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:672:7:
  error: label at end of compound statement is a C++23 extension
  [-Werror,-Wc++23-extensions]

While fixing bugs in the x86_64 LC_THREAD parser in ObjectFileMachO, I
noticed that the other LC_THREAD parsers are all less clear than they
should be.

To recap, a Mach-O LC_THREAD load command has a byte size for the entire
payload. Within the payload, there will be one or more register sets
provided. A register set starts with a UInt32 "flavor", the type of
register set defined in the system headers, and a UInt32 "count", the
number of UInt32 words of memory for this register set. After one
register set, there may be additional sets. A parser can skip an unknown
register set flavor by using the count field to get to the next register
set. When the total byte size of the LC_THREAD load command has been
parsed, it is completed.

This patch fixes the riscv/arm/arm64 LC_THREAD parsers to use the total
byte size as the exit condition, and to skip past unrecognized register
sets, instead of stopping parsing.

Instead of fixing the i386 corefile support, I removed it. The last
macOS that supported 32-bit Intel code was macOS 10.14 in 2018. I also
removed i386 KDP support, 32-bit intel kernel debugging hasn't been
supported for even longer than that.

It would be preferable to do these things separately, but I couldn't
bring myself to update the i386 LC_THREAD parser, and it required very
few changes to remove this support entirely.

From #143177. This combines the summaries for the pre- and post C++ 11
`std::string` as well as `std::wstring`. In all cases, the data pointer
is reachable through `_M_dataplus._M_p`. It has the correct type (i.e.
`char*`/`wchar_t*`) and it's null terminated, so LLDB knows how to
format it as expected when using `GetSummaryAsCString`.

Note that erase_if combines erase and remove_if.

This patch is part of an effort to remove the
`ResolveSDKPathFromDebugInfo` method, and more specifically the variant
which takes a Module as argument.

See the following PR for a follow up on what to do:
- https://github.com/llvm/llvm-project/pull/144913.

---------

Co-authored-by: Michael Buch <michaelbuch12@gmail.com>

This PR introduces support for the DWARF64 format, enabling handling of
64-bit DWARF sections as defined by the DWARF specification. The update
includes adjustments to header parsing and modification of form values
to accommodate 64-bit offsets and values.
Also Added the testcase to verify the DWARF64 format.

They are left over from our previous attempt at DWARF64. The new attempt
is not using them, and they also don't have equivalents in the llvm
DWARFDataExtractor class.