[lldb-dev] [Bug 42981] New: cross-compile lldb for ios fails

2019-08-13 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=42981

Bug ID: 42981
   Summary: cross-compile lldb for ios fails
   Product: lldb
   Version: 8.0
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: mryus...@live.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

i cross-compile lldb for ios, but it failed.
cmake -DCMAKE_CROSSCOMPILING=True
-DCMAKE_TOOLCHAIN_FILE=../cmake/platforms/IOS.cmake
-DCMAKE_IOS_SDK_ROOT=/Users/ruizhang/Documents/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.4.sdk
-DLLVM_TABLEGEN=/Users/ruizhang/Desktop/tsdb/third_party/llvm/build_mac/bin/llvm-tblgen
-DCLANG_TABLEGEN=/Users/ruizhang/Desktop/tsdb/third_party/llvm/build_mac/bin/clang-tblgen
-DLLVM_HOST_TRIPLE=aarch64-apple-darwin18 -DLLVM_TARGET_ARCH=AArch64
-DLLVM_TARGETS_TO_BUILD=AArch64 -DCMAKE_OSX_ARCHITECTURES="armv7;armv7s;arm64"
-DLLVM_ENABLE_RTTI=1 -DLLDB_DISABLE_LIBEDIT=1 -DLLDB_DISABLE_CURSES=1
-DLLDB_DISABLE_PYTHON=1 -DLLVM_ENABLE_TERMINFO=0 -DLLVM_ENABLE_PIC=False
-DLLVM_BUILD_TOOLS=OFF -DLLVM_BUILD_RUNTIME=OFF -DLLVM_BUILD_EXAMPLES=OFF
-DLLVM_BUILD_TESTS=OFF -DLLVM_ENABLE_BACKTRACES=OFF -DLLVM_INCLUDE_TESTS=OFF
-DLLDB_BUILD_FRAMEWORK=1 -DLLDB_CODESIGN_IDENTITY=lldb_codesign 
-DCMAKE_BUILD_TYPE=Release ../   

there is a lack of lockdown.h in cross-compiling. The detailed error
information is as follows:


/Users/ruizhang/Desktop/tsdb/third_party/llvm/tools/lldb/tools/debugserver/source/RNBSocket.h:24:10:
fatal error: 
  'lockdown.h' file not found
#include "lockdown.h"
 ^~~~
In file included from
/Users/ruizhang/Desktop/tsdb/third_party/llvm/tools/lldb/tools/debugserver/source/libdebugserver.cpp:23:
In file included from
/Users/ruizhang/Desktop/tsdb/third_party/llvm/tools/lldb/tools/debugserver/source/RNBRemote.h:21:
/Users/ruizhang/Desktop/tsdb/third_party/llvm/tools/lldb/tools/debugserver/source/RNBSocket.h:24:10:
fatal error: 
  'lockdown.h' file not found
#include "lockdown.h"
 ^~~~
1 error generated.
make[2]: ***
[tools/lldb/tools/debugserver/source/CMakeFiles/lldbDebugserverCommon.dir/libdebugserver.cpp.o]
Error 1
In file included from
/Users/ruizhang/Desktop/tsdb/third_party/llvm/tools/lldb/tools/debugserver/source/RNBContext.cpp:27:
In file included from
/Users/ruizhang/Desktop/tsdb/third_party/llvm/tools/lldb/tools/debugserver/source/RNBRemote.h:21:
[ 38%] Building CXX object
lib/Transforms/AggressiveInstCombine/CMakeFiles/LLVMAggressiveInstCombine.dir/TruncInstCombine.cpp.o
/Users/ruizhang/Desktop/tsdb/third_party/llvm/tools/lldb/tools/debugserver/source/RNBSocket.h:24:10:
fatal error: 
  'lockdown.h' file not found
#include "lockdown.h"
 ^~~~
1 error generated.
make[2]: ***
[tools/lldb/tools/debugserver/source/CMakeFiles/lldbDebugserverCommon.dir/RNBContext.cpp.o]
Error 1
[ 38%] Building CXX object
lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/BoundsChecking.cpp.o
1 error generated.
make[2]: ***
[tools/lldb/tools/debugserver/source/CMakeFiles/lldbDebugserverCommon.dir/RNBRemote.cpp.o]
Error 1
Scanning dependencies of target LLVMInstCombine
[ 38%] Building CXX object
lib/Transforms/InstCombine/CMakeFiles/LLVMInstCombine.dir/InstructionCombining.cpp.o
/Users/ruizhang/Desktop/tsdb/third_party/llvm/tools/lldb/tools/debugserver/source/MacOSX/MachProcess.mm:218:9:
fatal error: 
  'BackBoardServices/BKSOpenApplicationConstants_Private.h' file not found
#import 
^
1 error generated.
make[2]: ***
[tools/lldb/tools/debugserver/source/CMakeFiles/lldbDebugserverCommon.dir/MacOSX/MachProcess.mm.o]
Error 1
[ 38%] Building CXX object
lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/CGProfile.cpp.o
/Users/ruizhang/Desktop/tsdb/third_party/llvm/tools/lldb/tools/debugserver/source/MacOSX/MachTask.mm:54:9:
fatal error: 
  'BackBoardServices/BKSWatchdogAssertion.h' file not found
#import 
^~
1 error generated.
make[2]: ***
[tools/lldb/tools/debugserver/source/CMakeFiles/lldbDebugserverCommon.dir/MacOSX/MachTask.mm.o]
Error 1

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


[lldb-dev] lldb-mi has been moved to its own GitHub repository

2019-08-13 Thread Raphael “Teemperor” Isemann via lldb-dev
Hi all,

lldb-mi has been moved out of the LLDB source tree into its own GitHub 
repository here: https://github.com/lldb-tools/lldb-mi 
 lldb-mi is now a standalone tool that 
builds against LLDB, but is no longer build as part of LLDB. The implications 
for users are:

1. Package maintainers need to package lldb-mi and no longer receive the 
lldb-mi executable as a side product of LLDB. The lldb-mi build system is very 
simple, so I don’t expect a lot of problems arising from this change. Note: You 
can *NOT* drop in the lldb-mi source into the old folder inside the LLDB source 
tree. You need to first build LLDB and then build lldb-mi against it.

2. If you encounter bugs with lldb-mi, please file a report on the GitHub 
project and *NOT* on the LLVM bugzilla. We closed all lldb-mi bugs on bugzilla, 
so if you think your issue with lldb-mi still exists, please copy your bug 
report to GitHub.

In other news: lldb-mi is also in need of a maintainer!

The good thing is that with this change lldb-mi you can now make pull requests 
against the project, we set up a CI system and in general its easier to get 
started with lldb-mi. Note that during the move lldb-mi lost its test suit, 
meaning that there are currently no tests run in the CI. This was mostly 
because we couldn’t port over the old test suit (which depended on the internal 
LLDB python test suit) and because most of the tests we had were anyway 
disabled due to random failures. If you want to get started, feel free to make 
pull requests with tests (preferable more reliable than the old ones we had).

I’m mostly writing this as the change was buried in the RFC thread last month 
and it seems all downstream folks are still completely unaware this.

TL;DR: LLDB no longer provides the lldb-mi executable. You now need to 
get&compile lldb-mi from the GitHub repository above.

Cheers,
- Raphael

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


[lldb-dev] [Bug 42939] ios lldb cross-compiling

2019-08-13 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=42939

Jonas Devlieghere  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from Jonas Devlieghere  ---


*** This bug has been marked as a duplicate of bug 42981 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] lldb-mi has been moved to its own GitHub repository

2019-08-13 Thread Ted Woodward via lldb-dev
The build instructions in README.md are a tad sparse:
Build
cmake . ; cmake --build .


Where do we put it in relation to an lldb build?
Does it need the llvm/lldb sources?
Is it built against an lldb build, or an lldb install?

Ted

From: lldb-dev  On Behalf Of Raphael 
“Teemperor” Isemann via lldb-dev
Sent: Tuesday, August 13, 2019 3:18 AM
To: LLDB 
Subject: [EXT] [lldb-dev] lldb-mi has been moved to its own GitHub repository

Hi all,

lldb-mi has been moved out of the LLDB source tree into its own GitHub 
repository here: https://github.com/lldb-tools/lldb-mi lldb-mi is now a 
standalone tool that builds against LLDB, but is no longer build as part of 
LLDB. The implications for users are:

1. Package maintainers need to package lldb-mi and no longer receive the 
lldb-mi executable as a side product of LLDB. The lldb-mi build system is very 
simple, so I don’t expect a lot of problems arising from this change. Note: You 
can *NOT* drop in the lldb-mi source into the old folder inside the LLDB source 
tree. You need to first build LLDB and then build lldb-mi against it.

2. If you encounter bugs with lldb-mi, please file a report on the GitHub 
project and *NOT* on the LLVM bugzilla. We closed all lldb-mi bugs on bugzilla, 
so if you think your issue with lldb-mi still exists, please copy your bug 
report to GitHub.

In other news: lldb-mi is also in need of a maintainer!

The good thing is that with this change lldb-mi you can now make pull requests 
against the project, we set up a CI system and in general its easier to get 
started with lldb-mi. Note that during the move lldb-mi lost its test suit, 
meaning that there are currently no tests run in the CI. This was mostly 
because we couldn’t port over the old test suit (which depended on the internal 
LLDB python test suit) and because most of the tests we had were anyway 
disabled due to random failures. If you want to get started, feel free to make 
pull requests with tests (preferable more reliable than the old ones we had).

I’m mostly writing this as the change was buried in the RFC thread last month 
and it seems all downstream folks are still completely unaware this.

TL;DR: LLDB no longer provides the lldb-mi executable. You now need to 
get&compile lldb-mi from the GitHub repository above.

Cheers,
- Raphael

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] lldb-mi has been moved to its own GitHub repository

2019-08-13 Thread Raphael Isemann via lldb-dev
Agreed, I made a PR (which is work in progress):
https://github.com/lldb-tools/lldb-mi/pull/5 (I didn't try compiling
against a compiled LLDB, so that is subject to change).

Am Di., 13. Aug. 2019 um 19:29 Uhr schrieb Ted Woodward :
>
> The build instructions in README.md are a tad sparse:
>
> Build
>
> cmake . ; cmake --build .
>
>
>
>
>
> Where do we put it in relation to an lldb build?
>
> Does it need the llvm/lldb sources?
>
> Is it built against an lldb build, or an lldb install?
>
>
>
> Ted
>
>
>
> From: lldb-dev  On Behalf Of Raphael 
> “Teemperor” Isemann via lldb-dev
> Sent: Tuesday, August 13, 2019 3:18 AM
> To: LLDB 
> Subject: [EXT] [lldb-dev] lldb-mi has been moved to its own GitHub repository
>
>
>
> Hi all,
>
> lldb-mi has been moved out of the LLDB source tree into its own GitHub 
> repository here: https://github.com/lldb-tools/lldb-mi lldb-mi is now a 
> standalone tool that builds against LLDB, but is no longer build as part of 
> LLDB. The implications for users are:
>
> 1. Package maintainers need to package lldb-mi and no longer receive the 
> lldb-mi executable as a side product of LLDB. The lldb-mi build system is 
> very simple, so I don’t expect a lot of problems arising from this change. 
> Note: You can *NOT* drop in the lldb-mi source into the old folder inside the 
> LLDB source tree. You need to first build LLDB and then build lldb-mi against 
> it.
>
> 2. If you encounter bugs with lldb-mi, please file a report on the GitHub 
> project and *NOT* on the LLVM bugzilla. We closed all lldb-mi bugs on 
> bugzilla, so if you think your issue with lldb-mi still exists, please copy 
> your bug report to GitHub.
>
>
>
> In other news: lldb-mi is also in need of a maintainer!
>
>
>
> The good thing is that with this change lldb-mi you can now make pull 
> requests against the project, we set up a CI system and in general its easier 
> to get started with lldb-mi. Note that during the move lldb-mi lost its test 
> suit, meaning that there are currently no tests run in the CI. This was 
> mostly because we couldn’t port over the old test suit (which depended on the 
> internal LLDB python test suit) and because most of the tests we had were 
> anyway disabled due to random failures. If you want to get started, feel free 
> to make pull requests with tests (preferable more reliable than the old ones 
> we had).
>
>
>
> I’m mostly writing this as the change was buried in the RFC thread last month 
> and it seems all downstream folks are still completely unaware this.
>
>
>
> TL;DR: LLDB no longer provides the lldb-mi executable. You now need to 
> get&compile lldb-mi from the GitHub repository above.
>
>
>
> Cheers,
>
> - Raphael
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


[lldb-dev] "Correctly use GetLoadedModuleList to take advantage of libraries-svr4" can cause LLDB to abort

2019-08-13 Thread Ted Woodward via lldb-dev
Hi Antonio,

This is in regards to https://reviews.llvm.org/D64013 , specifically this code 
in ProcessGDBRemote::GetImageInfoAddress:

  if (addr == LLDB_INVALID_ADDRESS) {
llvm::Expected list = GetLoadedModuleList();
if (!list) {
  Log *log(ProcessGDBRemoteLog::GetLogIfAllCategoriesSet(GDBR_LOG_PROCESS));
  LLDB_LOG_ERROR(log, list.takeError(), "Failed to read module list: {0}");
} else {
  addr = list->m_link_map;
}
  }

If LLVM_ENABLE_ABI_BREAKING_CHECKS is set to 1 (which is true when asserts are 
enabled), llvm::Expected will call abort() if there is an error.
GetLoadedModuleList() has many reasons to set an error, including when XML is 
not available, or when the stub doesn't support remote modules.

I don't think we ever want to crash LLDB if the remote stub doesn't support 
something. I don't think llvm::Expected is the right solution here, and I think 
it should be removed.

Ted
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] "Correctly use GetLoadedModuleList to take advantage of libraries-svr4" can cause LLDB to abort

2019-08-13 Thread Jim Ingham via lldb-dev
IIUC an llvm::Expected is only supposed to abort if you leave its scope with an 
un-consumed error.  LLDB_LOG_ERROR is supposed to consume the error - the code 
looks like it is doing that.  So if you are still seeing an abort when there's 
an error, then it sounds like something is wrong with LLDB_LOG_ERROR.

Expected is supposed to force you to check the error - by aborting if you don't 
- but you are free to discard the error if it is non-fatal by consuming it, and 
then you should not abort.

Jim


> On Aug 13, 2019, at 11:19 AM, Ted Woodward via lldb-dev 
>  wrote:
> 
> Hi Antonio,
>  
> This is in regards to https://reviews.llvm.org/D64013 , specifically this 
> code in ProcessGDBRemote::GetImageInfoAddress:
>  
>   if (addr == LLDB_INVALID_ADDRESS) {
> llvm::Expected list = GetLoadedModuleList();
> if (!list) {
>   Log 
> *log(ProcessGDBRemoteLog::GetLogIfAllCategoriesSet(GDBR_LOG_PROCESS));
>   LLDB_LOG_ERROR(log, list.takeError(), "Failed to read module list: 
> {0}");
> } else {
>   addr = list->m_link_map;
> }
>   }
>  
> If LLVM_ENABLE_ABI_BREAKING_CHECKS is set to 1 (which is true when asserts 
> are enabled), llvm::Expected will call abort() if there is an error.
> GetLoadedModuleList() has many reasons to set an error, including when XML is 
> not available, or when the stub doesn’t support remote modules.
>  
> I don’t think we ever want to crash LLDB if the remote stub doesn’t support 
> something. I don’t think llvm::Expected is the right solution here, and I 
> think it should be removed.
>  
> Ted
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


[lldb-dev] [Bug 42981] cross-compile lldb for ios fails

2019-08-13 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=42981

Davide Italiano  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev