17 Commits

Author SHA1 Message Date
Jacob Lalonde
96b7c64b8a
[LLDB] Reapply SBSaveCore Add Memory List (#107937)
Recently in #107731 this change was revereted due to excess memory size
in `TestSkinnyCore`. This was due to a bug where a range's end was being
passed as size. Creating massive memory ranges.

Additionally, and requiring additional review, I added more unit tests
and more verbose logic to the merging of save core memory regions.

@jasonmolenda as an FYI.
2024-09-11 10:33:19 -07:00
Jonas Devlieghere
bb343468ff
Revert "[LLDB] Reappply SBSaveCore AddMemoryList" (#107731)
Reverts llvm/llvm-project#107159 as this is still causing
`TestSkinnyCorefile.py` to time out.


https://ci.swift.org/view/all/job/llvm.org/view/LLDB/job/as-lldb-cmake/11099/

https://ci.swift.org/view/all/job/llvm.org/view/LLDB/job/lldb-cmake/5544/
2024-09-07 17:10:20 -07:00
Jacob Lalonde
d4d4e77918
[LLDB] Reappply SBSaveCore AddMemoryList (#107159)
Reapplies #106293, testing identified issue in the merging code. I used
this opportunity to strip CoreFileMemoryRanges to it's own file and then
add unit tests on it's behavior.
2024-09-06 09:04:33 -07:00
Jacob Lalonde
b959532484
Revert "[LLDB][SBSaveCore] Add selectable memory regions to SBSaveCor… (#106293)
Reverts #105442. Due to `TestSkinnyCoreFailing` and root causing of the
failure will likely take longer than EOD.
2024-08-27 14:23:00 -07:00
Jacob Lalonde
d517b22411
[LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (#105442)
This patch adds the option to specify specific memory ranges to be
included in a given core file. The current implementation lets user
specified ranges either be in addition to a certain save style, or
independent of them via the newly added custom enum.

To achieve being inclusive of save style, I've moved from a std::vector
of ranges to a RangeDataVector, and to join overlapping ranges to
prevent duplication of memory ranges in the core file.

As a non function bonus, when SBSavecore was initially created, the
header was included in the lldb-private interfaces, and I've fixed that
and moved it the forward declare as an oversight. CC @bulbazord in case
we need to include that into swift.
2024-08-27 07:33:12 -07:00
Jacob Lalonde
572943e790
[LLDB] Reapply #100443 SBSaveCore Thread list (#104497)
Reapply #100443 and #101770. These were originally reverted due to a
test failure and an MSAN failure. I changed the test attribute to
restrict to x86 (following the other existing tests). I could not
reproduce the test or the MSAN failure and no repo steps were provided.
2024-08-15 16:29:59 -07:00
Haojian Wu
86f7374078 Revert "[LLDB][SBSaveCore] Fix bug where default values are not propagated. (#101770)"
This reverts commit 34766d0d488ba2fbefa80dcd0cc8720a0e753448 which
caused a msan failure, see comment https://github.com/llvm/llvm-project/pull/101770#issuecomment-2268373325 for details.
2024-08-05 09:37:36 +02:00
Jacob Lalonde
34766d0d48
[LLDB][SBSaveCore] Fix bug where default values are not propagated. (#101770)
In #100443, Mach-o and Minidump now only call process API's that take a
`SaveCoreOption` as the container for the style and information if a
thread should be included in the core or not. This introduced a bug
where in subsequent method calls we were not honoring the defaults of
both implementations.

~~To solve this I have made a copy of each SaveCoreOptions that is
mutable by the respective plugin. Originally I wanted to leave the
SaveCoreOptions as non const so these default value mutations could be
shown back to the user. Changing that behavior is outside of the scope
of this bugfix, but is context for why we are making a copy.~~

Removed const on the savecoreoptions so defaults can be inspected by the
user

CC: @Michael137
2024-08-02 18:38:05 -07:00
Jacob Lalonde
4120570dc4
[LLDB][SaveCore] Add SBSaveCoreOptions Object, and SBProcess::SaveCore() overload (#98403)
This PR adds `SBSaveCoreOptions`, which is a container class for options
when LLDB is taking coredumps. For this first iteration this container
just keeps parity with the extant API of `file, style, plugin`. In the
future this options object can be extended to allow users to take a
subset of their core dumps.
2024-07-18 17:10:15 -07:00
Jonas Devlieghere
f2ea125ea0
[lldb] Change CreateMemoryInstance to take a WritableDataBuffer
Change the CreateMemoryInstance interface to take a WritableDataBuffer.

Differential revision: https://reviews.llvm.org/D123073
2022-04-05 13:46:41 -07:00
Jonas Devlieghere
c69307e5ee
[lldb] Prevent object file plugins from changing the data buffer
The current design allows that the object file contents could be mapped
by one object file plugin and then used by another. Presumably the idea
here was to avoid mapping the same file twice.

This becomes an issue when one object file plugin wants to map the file
differently from the others. For example, ObjectFileELF needs to map its
memory as writable while others likeObjectFileMachO needs it to be
mapped read-only.

This patch prevents plugins from changing the buffer by passing them is
by value rather than by reference.

Differential revision: https://reviews.llvm.org/D122944
2022-04-04 09:24:24 -07:00
Pavel Labath
2ace1e5753 [lldb] Remove ConstString from GetPluginNameStatic of some plugins
This patch deals with ObjectFile, ObjectContainer and OperatingSystem
plugins. I'll convert the other types in separate patches.

In order to enable piecemeal conversion, I am leaving some ConstStrings
in the lowest PluginManager layers. I'll convert those as the last step.

Differential Revision: https://reviews.llvm.org/D112061
2021-10-21 12:58:45 +02:00
Pavel Labath
a3939e159f [lldb] Return StringRef from PluginInterface::GetPluginName
There is no reason why this function should be returning a ConstString.

While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.

I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.

Differential Revision: https://reviews.llvm.org/D111877
2021-10-18 10:14:42 +02:00
Pavel Labath
b03126768a [lldb] Remove PluginInterface::GetPluginVersion
In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.

Differential Revision: https://reviews.llvm.org/D109600
2021-09-13 10:29:00 +02:00
Andrej Korman
eee687a66d [lldb] Add minidump save-core functionality to ELF object files
This change adds save-core functionality into the ObjectFileELF that enables
saving minidump of a stopped process. This change is mainly targeting Linux
running on x86_64 machines. Minidump should contain basic information needed
to examine state of threads, local variables and stack traces. Full support
for other platforms is not so far implemented. API tests are using LLDB's
MinidumpParser.

This relands commit aafa05e, reverted in 1f986f6.
Failed tests were fixed.

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D108233
2021-09-01 15:14:29 +02:00
Andy Yankovsky
1f986f6057 Revert "[lldb] Add minidump save-core functionality to ELF object files"
This reverts commit aafa05e03d629cc6605718c54575256d9d683659.

Broke builder on aarch64 --
https://lab.llvm.org/buildbot/#/builders/96/builds/10926
2021-08-31 13:36:53 +02:00
Andrej Korman
aafa05e03d [lldb] Add minidump save-core functionality to ELF object files
This change adds save-core functionality into the ObjectFileELF that enables
saving minidump of a stopped process. This change is mainly targeting Linux
running on x86_64 machines. Minidump should contain basic information needed
to examine state of threads, local variables and stack traces. Full support
for other platforms is not so far implemented. API tests are using LLDB's
MinidumpParser.

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D108233
2021-08-31 13:04:38 +02:00