llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `llvm-x86_64-debian-dylib`
running on `gribozavr4` while building `lldb` at step 5 "build-unified-tree".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/60/builds/6830
Here is the relevant piece of the
Author: Jonas Devlieghere
Date: 2024-09-07T17:03:59-07:00
New Revision: b93457073762bb347b6c7f39c23636dec036a815
URL:
https://github.com/llvm/llvm-project/commit/b93457073762bb347b6c7f39c23636dec036a815
DIFF:
https://github.com/llvm/llvm-project/commit/b93457073762bb347b6c7f39c23636dec036a815.d
https://github.com/JDevlieghere closed
https://github.com/llvm/llvm-project/pull/107731
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jonas Devlieghere (JDevlieghere)
Changes
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/vie
https://github.com/JDevlieghere created
https://github.com/llvm/llvm-project/pull/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/j
JDevlieghere wrote:
CC @Jlalond
https://github.com/llvm/llvm-project/pull/107731
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Jonas Devlieghere
Date: 2024-09-07T17:10:20-07:00
New Revision: bb343468ffa8c2190fcdd0f704d370c75d3b5edd
URL:
https://github.com/llvm/llvm-project/commit/bb343468ffa8c2190fcdd0f704d370c75d3b5edd
DIFF:
https://github.com/llvm/llvm-project/commit/bb343468ffa8c2190fcdd0f704d370c75d3b5edd.d
jasonmolenda wrote:
I'll look more closely later when I have time, but ObjectFileMachO::SaveCore
called `Process::CalculateCoreFileSaveRanges` with an `options` of
`eSaveCoreDirtyOnly` (so, `GetCoreFileSaveRangesDirtyOnly()`), it's returning
gigantic memory regions to be saved to the corefile.
Jlalond wrote:
> I'll look more closely later when I have time, but ObjectFileMachO::SaveCore
> called `Process::CalculateCoreFileSaveRanges` with an `options` of
> `eSaveCoreDirtyOnly` (so, `GetCoreFileSaveRangesDirtyOnly()`), it's returning
> gigantic memory regions to be saved to the corefi
