HomePhabricator

[LLDB] Fix FreeBSD build.

Description

[LLDB] Fix FreeBSD build.

To align with the LaunchThread change.

Reviewers: MaskRay, mgorny

Reviewed By: MaskRay

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

Details

Committed
devnexenJul 11 2019, 5:21 AM
Reviewer
MaskRay
Differential Revision
Restricted Differential Revision
Parents
rL365760: [ELF] Handle non-glob patterns before glob patterns in version scripts & fix a…
Branches
Unknown
Tags
Unknown

Event Timeline

@devnexen this appears to cause https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241137, where simply launching a process in lldb triggers a failure:

Expected<T> must be checked before access or destruction.
Expected<T> value was in success state. (Note: Expected<T> values in success mode must still be checked prior to being destroyed).

This is occurring when calling operator-> in this part:

792       if (m_operation_thread->IsJoinable())
793         return;
dim added a comment.Oct 9 2019, 11:53 AM

@devnexen this appears to cause https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241137, where simply launching a process in lldb triggers a failure:

Expected<T> must be checked before access or destruction.
Expected<T> value was in success state. (Note: Expected<T> values in success mode must still be checked prior to being destroyed).

Btw, note that this only happens when LLVM_ENABLE_ABI_BREAKING_CHECKS is on, but it is not entirely clear to me where that gets toggled. We have it in our pre-generated headers though, so it must come originally from some CMake logic...

devnexen added a comment.EditedOct 9 2019, 7:47 PM

@devnexen this appears to cause https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241137, where simply launching a process in lldb triggers a failure:

Expected<T> must be checked before access or destruction.
Expected<T> value was in success state. (Note: Expected<T> values in success mode must still be checked prior to being destroyed).

Btw, note that this only happens when LLVM_ENABLE_ABI_BREAKING_CHECKS is on, but it is not entirely clear to me where that gets toggled. We have it in our pre-generated headers though, so it must come originally from some CMake logic...

@dim I might a fix for but do not know if it is doable to commit to the 9.x branch or if I have to go through bugzilla system for it.