Please support Apple silicon (M1, arm64-darwin)

Hello!
it would be great if vscode-lldb could support arm64-darwin (the new Mac M1 SoC)
Thanks!

I think it'll happen at some point, but don't hold your breath.  It will take a while to figure out how to cross-compile native components, and then there's the question of testing - I don't have an arm64 Mac.

You could release an experimental branch, I'd be happy to test it and I'm sure others would too.

I also can help to test it.

By the way, what happens today if you install CodeLLDB on an arm mac?

The extension installs without any reported errors, but when you try and launch a debug session with it you get:

I wonder if you could just run the x64 version under Rosetta.
If you'd like to try that:

Install extension.
Open $HOME/.vscode/extensions/vadimcn.vscode-lldb-1.6.0/package.json in a text editor.
Find platforms section (near the bottom).
Add "arm64-darwin": "codelldb-x86_64-darwin.vsix", line into it.
Restart VSCode, see if debugging works.

Folks, I managed to get it working on the Exploration version of VSCode. Pull request above.
I am having an hard time building and packing llvm-project stuff. I would appreciate any help :)

I wonder if you could just run the x64 version under Rosetta.

I didn't they this. I may be wrong, but I don't have much hope..
The problem with Rosetta is that everything spawned from a process running in emulation is also in emulation.
I had to switch to VSCode Exploratory and build rust analyser, to build and use native Rust binaries...

I could reduce the file size, but I have no idea how to create a package which doesn't depend on my environment...
Anyway, this is it
https://www.icloud.com/iclouddrive/0lxZDEqpFo6d_J_rWgaI0cJug#codelldb-aarch64-darwin

I will write a quick guide later today! ;)

Build vscode-lldb for M1 (aarch64 native)
Official building instructions:
https://github.com/vadimcn/vscode-lldb/blob/master/BUILDING.md
Prerequisites
You will need VSCode Exploratory as M1 is still not supported by VSCode Insider or Stable.
Install Xcode tools
xcode-select —install

Install Rust
Rust (rustip) stable is still not available on M1. This will change soon, but for now, see this thread https://github.com/rust-lang/rustup/issues/2413
Install Macports
I use Macports, I think Homebrew (native for M1) should work too, bit in this guide I am assuming you bave Macports installed.
https://www.macports.org
[optional] ccache
At this stage, if you want native stuff for your Mac, chances are that you are going toneed to build (and rebuild) a lot of stuff.
So, I recommend installing ccache.
Of course, this is not going to save you time for llvm (see below), at least the first time.
llvm and vscode-lldb dependecies
sudo port install cmake nodejs15 npm6

Building stuff
build llvm
git clone https://github.com/llvm/llvm-project.git
cd llvm-project ; mkdir build ; cd build
cmake ../llvm -DLLVM_ENABLE_PROJECTS="clang;libcxx;lldb"
make lldb lldb-server

That is going to take a while.
zip llvm
cd lldb
zip -r lldb-m1.zip bin/ lib/liblldb.12.0.0git.dylib lib/liblldb.dylib

The content of the archive will be used by vscode-lldb later.
Note that the content of lldb-m1.zip will probably only work on your local machine as a lot of other dependencies are left outside (e.g. debugserver and required libs).
building vscode-lldb
git clone https://github.com/vadimcn/vscode-lldb.git
cd vscode-lldb
git submodule update --init --recursive
npm install
mkdir build ; cd build
mkdir lldb
mv <location of lldb-m1.zip you create belore> lldb/
LLDB_PACKAGE=./lldb-m1.zip cmake ..
make vsix_full

If everything goes well:
mv codelldb-full.vsix codelldb-aarch64-darwin.vsix

Install the official vscode-lldb extension and reload.
Install codelldb-aarch64-darwin.vsix via "Install from VSIX..." in the extension menu of VSCode Exploratory.

I didn't try this. I may be wrong, but I don't have much hope..

Could somebody with M1 Mac try this out please?

Could somebody with M1 Mac try this out please?

On Exploration and Stable, debug fails with -1. In system logs I see:
default	13:31:25.484895+0000	debugserver	debugserver will use os_log for internal logging.
default	13:31:25.485389+0000	debugserver	debugserver-@(#)PROGRAM:debugserver  PROJECT:debugserver-1<IP_ADDRESS>
 for x86_64.
default	13:31:25.485477+0000	debugserver	Got a connection, waiting for process information for launching or attaching.
default	13:31:25.523638+0000	debugserver	1 +0.000000 sec [13158/0203]: error: ::task_set_exception_ports ( task = 0x5403, exception_mask = 0x00001bfe, new_port = 0x5303, behavior = 0x80000001, new_flavor = 0x0000000d ) err = (os/kern) invalid argument (0x00000004)
error	13:31:25.523756+0000	debugserver	error: Attach failed: "(os/kern) invalid argument".
default	13:31:25.523777+0000	debugserver	error: attach failed.
default	13:31:25.523829+0000	debugserver	2 +0.000211 sec [13158/1b03]: error: ::read ( 15, 0x30ccbbb10, 1024 ) => -1 err = Bad file descriptor (0x00000009)
default	13:31:25.523859+0000	debugserver	Exiting.

I think this is because the process is aarch64 but debugserver is expecting x86_64.
The Rust binary I am trying to debug is for arm64 as the system rust is native. I wonder what happens using Rosetta and x86 rustc...

I wonder if you could just run the x64 version under Rosetta.
If you'd like to try that:

Install extension.
Open $HOME/.vscode/extensions/vadimcn.vscode-lldb-1.6.0/package.json in a text editor.
Find platforms section (near the bottom).
Add "arm64-darwin": "codelldb-x86_64-darwin.vsix", line into it.
Restart VSCode, see if debugging works.

It does not work.
With the VSCode Rosetta Version aka the normal one the debugger loads the default Mac x86 and fails with error 1
Doing it with the arm Insider Version (which displays normally in unsupported Plattform) results the same
How is lldb called? Maybe if its called from bash it has to be" arch -x86_64 lldb" instead "lldb" for the x86 version

@dguerri:  I would prefer not to release code I cannot personally build and test myself, because I am sure there will be problems that other users will hit (they always do) and this will come back to me, and I won't be able to do anything about it.
You could argue that the same may happen if running under Rosetta, and I would agree.   I am still not convinced that I want to do this, but at least the extra effort spent on that would be minimal.
Longer term, I hope that cloud CI systems catch up with Apple silicon and figure out how to build and test for it.    Maybe somebody will figure out how to emulate arm64 OSX in a VM, or, perhaps, some cloud provider will offer Apple hardware that can be remoted into.
Regarding your findings (and thanks for trying this out!):

On Exploration and Stable, debug fails with -1. In system logs I see:

Could you please also attach codelldb's verbose log?

I think this is because the process is aarch64 but debugserver is expecting x86_64.

There's no obvious reason (to me at least), why x86 debugger could not debug arm executables.  After all, this is routinely done during remote debugging.
There's a way to specify target architecture in lldb - you need to use custom launch and use target create --arch aarch64 <filename> to create the debug target.
In case there is indeed a restriction on architecture of the process using debugging APIs, here's another thing to try: set LLDB_DEBUGSERVER_PATH=<path to arm64 debugserver> via lldb.adapterEnv.
Thanks!

This is with default VSCode Rosetta Version
`warning: function is never used: `get_adjacent`
   --> src/main.rs:115:4
    |
115 | fn get_adjacent(place : &Place,v: &[Vec<Place>]) -> usize {
    |    ^^^^^^^^^^^^

warning: 34 warnings emitted

    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
Raw artifacts:
{
  fileName: '/Users/user/Documents/git/coding-advent-2020/day11/target/debug/day11',
  name: 'day11',
  kind: 'bin'
}
configuration: {
  type: 'lldb',
  request: 'launch',
  name: 'Cargo launch',
  program: '/Users/user/Documents/git/coding-advent-2020/day11/target/debug/day11',
  args: [],
  __configurationTarget: 5,
  relativePathBase: '/Users/user/Documents/git/coding-advent-2020/day11',
  sourceLanguages: [ 'rust' ]
}
liblldb: /Users/user/.vscode/extensions/vadimcn.vscode-lldb-1.6.0/lldb/lib/liblldb.dylib
environment: {}
params: { sourceLanguages: [ 'rust' ] }
Listening on port 55750
[2020-12-22T13:30:28Z DEBUG codelldb] New debug session
INFO(Python) 14:30:28 formatters: Initializing
INFO(Python) 14:30:28 formatters.rust: Initializing
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] --> {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"lldb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us","supportsProgressReporting":true,"supportsInvalidatedEvent":true},"type":"request","seq":1}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":1,"success":true,"command":"initialize","body":{"exceptionBreakpointFilters":[{"default":true,"filter":"rust_panic","label":"Rust: on panic"}],"supportTerminateDebuggee":true,"supportsCancelRequest":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsEvaluateForHovers":true,"supportsFunctionBreakpoints":true,"supportsGotoTargetsRequest":true,"supportsHitConditionalBreakpoints":true,"supportsLogPoints":true,"supportsReadMemoryRequest":true,"supportsRestartFrame":true,"supportsSetVariable":true}}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] --> {"command":"launch","arguments":{"type":"lldb","request":"launch","name":"Cargo launch","program":"/Users/user/Documents/git/coding-advent-2020/day11/target/debug/day11","args":[],"__configurationTarget":5,"relativePathBase":"/Users/user/Documents/git/coding-advent-2020/day11","sourceLanguages":["rust"],"_adapterSettings":{"displayFormat":"auto","showDisassembly":"auto","dereferencePointers":true,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null,"terminalPromptClear":null},"__sessionId":"cec01fc1-85d0-4c8f-90c3-0549393de6c7"},"type":"request","seq":2}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":1,"event":"initialized"}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] <-- {"type":"request","seq":2,"command":"runInTerminal","arguments":{"args":["/Users/user/.vscode/extensions/vadimcn.vscode-lldb-1.6.0/adapter/codelldb","terminal-agent","--port=55752"],"cwd":"","kind":"integrated","title":"Cargo launch"}}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints","arguments":{"source":{"name":"main.rs","path":"/Users/user/Documents/git/coding-advent-2020/day11/src/main.rs"},"lines":[13],"breakpoints":[{"line":13}],"sourceModified":false},"type":"request","seq":3}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"line":13,"message":"Locations: 1","verified":true}]}}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] --> {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":4,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] --> {"command":"setDataBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":5}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":5,"success":true,"command":"setDataBreakpoints","body":{"breakpoints":[]}}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] --> {"command":"setExceptionBreakpoints","arguments":{"filters":["rust_panic"]},"type":"request","seq":6}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":6,"success":true,"command":"setExceptionBreakpoints"}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] --> {"type":"response","seq":7,"command":"runInTerminal","request_seq":2,"success":true,"body":{"shellProcessId":43675}}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] --> {"command":"configurationDone","type":"request","seq":8}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":8,"success":true,"command":"configurationDone"}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] --> {"command":"threads","type":"request","seq":9}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":9,"success":true,"command":"threads","body":{"threads":[]}}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":3,"event":"output","body":{"output":"Launching: /Users/user/Documents/git/coding-advent-2020/day11/target/debug/day11\n"}}
[2020-12-22T13:30:28Z ERROR codelldb::debug_session] process exited with status -1 (Error 1)
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":2,"success":false,"message":"process exited with status -1 (Error 1)","show_user":true}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] --> {"command":"disconnect","arguments":{"restart":false},"type":"request","seq":10}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":10,"success":true,"command":"disconnect"}
[2020-12-22T13:30:28Z DEBUG codelldb::dap_session] Client has disconnected
[2020-12-22T13:30:28Z DEBUG codelldb::debug_session] End of the requests stream
[2020-12-22T13:30:28Z DEBUG codelldb::debug_session] DebugSession::drop()
[2020-12-22T13:30:28Z DEBUG codelldb] Session has ended
[2020-12-22T13:30:28Z DEBUG codelldb] Exiting
Debug adapter exit code=0, signal=null.`

I would prefer not to release code I cannot personally build and test myself

100% understandable. No pressure whatsoever and I am willing to help with the Rosetta alternative.
Nevertheless, how would you feel about tagging it as an experimental, unsupported, version?
After all this is only going to work on Exploration, for now. After testing on other platforms the new package.lock, the PR should not touch anything else.
I can commit in the medium-short term to test and fix issues with the M1 native version and I am sure others will be happy to participate (for instance, @KulSthl too ;) ).
I see @KulSthl has already submitted some logs, I will try to help with the other tests as soon as I can!
Thanks 👍

There's a way to specify target architecture in lldb - you need to use custom launch and use target create --arch aarch64  to create the debug target.

x86 Rust x86Vscode
configuration: {
  type: 'lldb',
  request: 'launch',
  name: 'Custom launch',
  targetCreateCommands: [
    'target create --arch x86_64-apple-macosx11.0.0 target/debug/day11'
  ],
  processCreateCommands: [ 'process launch --stop-at-entry' ],
  __configurationTarget: 5,
  custom: true,
  relativePathBase: '/Users/user/Documents/git/coding-advent-2020/day11'
}
liblldb: /Users/user/.vscode/extensions/vadimcn.vscode-lldb-1.6.0/lldb/lib/liblldb.dylib
environment: {}
params: {}
Listening on port 56343
[2020-12-22T14:02:23Z DEBUG codelldb] New debug session
INFO(Python) 15:02:23 formatters: Initializing
INFO(Python) 15:02:23 formatters.rust: Initializing
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] --> {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"lldb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us","supportsProgressReporting":true,"supportsInvalidatedEvent":true},"type":"request","seq":1}
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":1,"success":true,"command":"initialize","body":{"exceptionBreakpointFilters":[{"default":true,"filter":"cpp_throw","label":"C++: on throw"},{"default":false,"filter":"cpp_catch","label":"C++: on catch"}],"supportTerminateDebuggee":true,"supportsCancelRequest":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsEvaluateForHovers":true,"supportsFunctionBreakpoints":true,"supportsGotoTargetsRequest":true,"supportsHitConditionalBreakpoints":true,"supportsLogPoints":true,"supportsReadMemoryRequest":true,"supportsRestartFrame":true,"supportsSetVariable":true}}
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] --> {"command":"launch","arguments":{"type":"lldb","request":"launch","name":"Custom launch","targetCreateCommands":["target create --arch x86_64-apple-macosx11.0.0 target/debug/day11"],"processCreateCommands":["process launch --stop-at-entry"],"__configurationTarget":5,"custom":true,"relativePathBase":"/Users/user/Documents/git/coding-advent-2020/day11","_adapterSettings":{"displayFormat":"auto","showDisassembly":"auto","dereferencePointers":true,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null,"terminalPromptClear":null},"__sessionId":"ee8078a0-6b20-45b7-ac60-a90ef9681b42"},"type":"request","seq":2}
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":1,"event":"output","body":{"output":"Executing script: targetCreateCommands\n"}}
[2020-12-22T14:02:23Z DEBUG codelldb::debug_session] target create --arch x86_64-apple-macosx11.0.0 target/debug/day11 -> SuccessFinishNoResult, Error:  Success
Output Message:
Current executable set to '/Users/user/Documents/git/coding-advent-2020/day11/target/debug/day11' (x86_64).

[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":2,"event":"output","body":{"output":"Current executable set to '/Users/user/Documents/git/coding-advent-2020/day11/target/debug/day11' (x86_64).\n\n"}}
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":3,"event":"initialized"}
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints","arguments":{"source":{"name":"main.rs","path":"/Users/user/Documents/git/coding-advent-2020/day11/src/main.rs"},"lines":[13],"breakpoints":[{"line":13}],"sourceModified":false},"type":"request","seq":3}
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"line":13,"message":"Locations: 1","verified":true}]}}
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] --> {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4}
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":4,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] --> {"command":"setDataBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":5}
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":5,"success":true,"command":"setDataBreakpoints","body":{"breakpoints":[]}}
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] --> {"command":"setExceptionBreakpoints","arguments":{"filters":["cpp_throw"]},"type":"request","seq":6}
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":6,"success":true,"command":"setExceptionBreakpoints"}
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] --> {"command":"configurationDone","type":"request","seq":7}
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":7,"success":true,"command":"configurationDone"}
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":4,"event":"output","body":{"output":"Executing script: processCreateCommands\n"}}
[2020-12-22T14:02:23Z DEBUG codelldb::dap_codec] --> {"command":"threads","type":"request","seq":8}
[2020-12-22T14:02:25Z DEBUG codelldb::debug_session] process launch --stop-at-entry -> SuccessFinishResult, Error:  Success
Output Message:
Process 44929 launched: '/Users/user/Documents/git/coding-advent-2020/day11/target/debug/day11' (x86_64)

[2020-12-22T14:02:25Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":5,"event":"output","body":{"output":"Process 44929 launched: '/Users/user/Documents/git/coding-advent-2020/day11/target/debug/day11' (x86_64)\n\n"}}
[2020-12-22T14:02:25Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":2,"success":true,"command":"launch"}
[2020-12-22T14:02:25Z DEBUG codelldb::debug_session] Debug event: 0x7fbd46c20188 Event: broadcaster = 0x7fbd5004c020 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-12-22T14:02:25Z DEBUG codelldb::debug_session] Debug event: 0x7fbd46c13d38 Event: broadcaster = 0x7fbd5004c020 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-12-22T14:02:25Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":8,"success":true,"command":"threads","body":{"threads":[{"id":339615,"name":"1: tid=339615"}]}}
[2020-12-22T14:02:25Z DEBUG codelldb::debug_session] Debug event: 0x7fbd46d542d8 Event: broadcaster = 0x7fbd5004c020 (lldb.target), type = 0x00000002 (modules-loaded), data = {dyld, runtime}
[2020-12-22T14:02:25Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":6,"event":"module","body":{"module":{"addressRange":"2000A8000","id":"2000A8000","name":"dyld","path":"/usr/lib/dyld","symbolFilePath":"/usr/lib/dyld","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-12-22T14:02:25Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":7,"event":"module","body":{"module":{"addressRange":"7FFDFFF78000","id":"7FFDFFF78000","name":"runtime","path":"/Library/Apple/usr/libexec/oah/runtime","symbolFilePath":"/Library/Apple/usr/libexec/oah/runtime","symbolStatus":"Symbols loaded."},"reason":"new"}}

This is not showing an error but debugging is not working. Maybe my configuration is wrong?

Arm Rust x86 Vscode
configuration: {
  type: 'lldb',
  request: 'launch',
  name: 'Custom launch',
  preLaunchTask: 'cbuild',
  targetCreateCommands: [
    'target create --arch arm64-apple-macosx11.0.0 target/debug/day11'
  ],
  processCreateCommands: [ 'process launch --stop-at-entry' ],
  __configurationTarget: 5,
  custom: true,
  relativePathBase: '/Users/user/Documents/git/coding-advent-2020/day11'
}
liblldb: /Users/user/.vscode/extensions/vadimcn.vscode-lldb-1.6.0/lldb/lib/liblldb.dylib
environment: {}
params: {}
Listening on port 56681
[2020-12-22T14:24:01Z DEBUG codelldb] New debug session
INFO(Python) 15:24:01 formatters: Initializing
INFO(Python) 15:24:01 formatters.rust: Initializing
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] --> {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"lldb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us","supportsProgressReporting":true,"supportsInvalidatedEvent":true},"type":"request","seq":1}
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":1,"success":true,"command":"initialize","body":{"exceptionBreakpointFilters":[{"default":true,"filter":"cpp_throw","label":"C++: on throw"},{"default":false,"filter":"cpp_catch","label":"C++: on catch"}],"supportTerminateDebuggee":true,"supportsCancelRequest":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsEvaluateForHovers":true,"supportsFunctionBreakpoints":true,"supportsGotoTargetsRequest":true,"supportsHitConditionalBreakpoints":true,"supportsLogPoints":true,"supportsReadMemoryRequest":true,"supportsRestartFrame":true,"supportsSetVariable":true}}
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] --> {"command":"launch","arguments":{"type":"lldb","request":"launch","name":"Custom launch","preLaunchTask":"cbuild","targetCreateCommands":["target create --arch arm64-apple-macosx11.0.0 target/debug/day11"],"processCreateCommands":["process launch --stop-at-entry"],"__configurationTarget":5,"custom":true,"relativePathBase":"/Users/user/Documents/git/coding-advent-2020/day11","_adapterSettings":{"displayFormat":"auto","showDisassembly":"auto","dereferencePointers":true,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null,"terminalPromptClear":null},"__sessionId":"cc8d4839-747c-4b15-abb7-4ae3542d97f1"},"type":"request","seq":2}
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":1,"event":"output","body":{"output":"Executing script: targetCreateCommands\n"}}
[2020-12-22T14:24:01Z DEBUG codelldb::debug_session] target create --arch arm64-apple-macosx11.0.0 target/debug/day11 -> SuccessFinishNoResult, Error:  Success
Output Message:
Current executable set to '/Users/user/Documents/git/coding-advent-2020/day11/target/debug/day11' (arm64).

[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":2,"event":"output","body":{"output":"Current executable set to '/Users/user/Documents/git/coding-advent-2020/day11/target/debug/day11' (arm64).\n\n"}}
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":3,"event":"initialized"}
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints","arguments":{"source":{"name":"main.rs","path":"/Users/user/Documents/git/coding-advent-2020/day11/src/main.rs"},"lines":[13],"breakpoints":[{"line":13}],"sourceModified":false},"type":"request","seq":3}
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"line":13,"message":"Locations: 1","verified":true}]}}
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] --> {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4}
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":4,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] --> {"command":"setDataBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":5}
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":5,"success":true,"command":"setDataBreakpoints","body":{"breakpoints":[]}}
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] --> {"command":"setExceptionBreakpoints","arguments":{"filters":["cpp_throw"]},"type":"request","seq":6}
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":6,"success":true,"command":"setExceptionBreakpoints"}
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] --> {"command":"configurationDone","type":"request","seq":7}
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":7,"success":true,"command":"configurationDone"}
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":4,"event":"output","body":{"output":"Executing script: processCreateCommands\n"}}
[2020-12-22T14:24:01Z DEBUG codelldb::dap_codec] --> {"command":"threads","type":"request","seq":8}
[2020-12-22T14:24:03Z DEBUG codelldb::debug_session] process launch --stop-at-entry -> SuccessFinishResult, Error:  Success
Output Message:
Process 46161 launched: '/Users/user/Documents/git/coding-advent-2020/day11/target/debug/day11' (arm64)

[2020-12-22T14:24:03Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":5,"event":"output","body":{"output":"Process 46161 launched: '/Users/user/Documents/git/coding-advent-2020/day11/target/debug/day11' (arm64)\n\n"}}
[2020-12-22T14:24:03Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":2,"success":true,"command":"launch"}
[2020-12-22T14:24:03Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":8,"success":true,"command":"threads","body":{"threads":[]}}
[2020-12-22T14:24:06Z DEBUG codelldb::debug_session] Debug event: 0x7fac9de645d0 Event: broadcaster = 0x7fac9e107058 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x7fac9e107018 (pid = 46161), state = exited}
[2020-12-22T14:24:06Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":6,"event":"output","body":{"output":"Process exited with code -1.\n"}}
[2020-12-22T14:24:06Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":7,"event":"exited","body":{"exitCode":-1}}
[2020-12-22T14:24:06Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":8,"event":"terminated","body":{}}
[2020-12-22T14:24:06Z DEBUG codelldb::dap_codec] --> {"command":"disconnect","arguments":{"restart":false},"type":"request","seq":9}
[2020-12-22T14:24:06Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":9,"success":true,"command":"disconnect"}
[2020-12-22T14:24:06Z DEBUG codelldb::dap_session] Client has disconnected
[2020-12-22T14:24:06Z DEBUG codelldb::debug_session] End of the requests stream
[2020-12-22T14:24:06Z DEBUG codelldb::debug_session] DebugSession::drop()
[2020-12-22T14:24:06Z DEBUG codelldb] Session has ended
[2020-12-22T14:24:06Z DEBUG codelldb] Exiting
Debug adapter exit code=0, signal=null.

Prints error

x86 Rust x86 Vscode

In case there is indeed a restriction on architecture of the process using debugging APIs, here's another thing to try: set LLDB_DEBUGSERVER_PATH= via lldb.adapterEnv.

  type: 'lldb',
  request: 'launch',
  name: 'Custom launch',
  preLaunchTask: 'cbuild',
  targetCreateCommands: [
    'target create --arch x86_64-apple-macosx11.0.0 target/debug/day11'
  ],
  processCreateCommands: [ 'process launch --stop-at-entry' ],
  __configurationTarget: 5,
  custom: true,
  relativePathBase: '/Users/user/Documents/git/coding-advent-2020/day11'
}
liblldb: /Users/user/.vscode/extensions/vadimcn.vscode-lldb-1.6.0/lldb/lib/liblldb.dylib
environment: {
  LLDB_DEBUGSERVER_PATH: '/Users/user/llvm-project/build/bin/lldb-server'
}
params: {}
Listening on port 57022
[2020-12-22T14:42:57Z DEBUG codelldb] New debug session
INFO(Python) 15:42:58 formatters: Initializing
INFO(Python) 15:42:58 formatters.rust: Initializing
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] --> {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"lldb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us","supportsProgressReporting":true,"supportsInvalidatedEvent":true},"type":"request","seq":1}
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":1,"success":true,"command":"initialize","body":{"exceptionBreakpointFilters":[{"default":true,"filter":"cpp_throw","label":"C++: on throw"},{"default":false,"filter":"cpp_catch","label":"C++: on catch"}],"supportTerminateDebuggee":true,"supportsCancelRequest":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsEvaluateForHovers":true,"supportsFunctionBreakpoints":true,"supportsGotoTargetsRequest":true,"supportsHitConditionalBreakpoints":true,"supportsLogPoints":true,"supportsReadMemoryRequest":true,"supportsRestartFrame":true,"supportsSetVariable":true}}
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] --> {"command":"launch","arguments":{"type":"lldb","request":"launch","name":"Custom launch","preLaunchTask":"cbuild","targetCreateCommands":["target create --arch x86_64-apple-macosx11.0.0 target/debug/day11"],"processCreateCommands":["process launch --stop-at-entry"],"__configurationTarget":5,"custom":true,"relativePathBase":"/Users/user/Documents/git/coding-advent-2020/day11","_adapterSettings":{"displayFormat":"auto","showDisassembly":"auto","dereferencePointers":true,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null,"terminalPromptClear":null},"__sessionId":"7d1c4acd-a3e2-4a86-8272-a9b4b20dbf97"},"type":"request","seq":2}
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":1,"event":"output","body":{"output":"Executing script: targetCreateCommands\n"}}
[2020-12-22T14:42:58Z DEBUG codelldb::debug_session] target create --arch x86_64-apple-macosx11.0.0 target/debug/day11 -> SuccessFinishNoResult, Error:  Success
Output Message:
Current executable set to '/Users/user/Documents/git/coding-advent-2020/day11/target/debug/day11' (x86_64).

[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":2,"event":"output","body":{"output":"Current executable set to '/Users/user/Documents/git/coding-advent-2020/day11/target/debug/day11' (x86_64).\n\n"}}
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":3,"event":"initialized"}
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints","arguments":{"source":{"name":"main.rs","path":"/Users/user/Documents/git/coding-advent-2020/day11/src/main.rs"},"lines":[13],"breakpoints":[{"line":13}],"sourceModified":false},"type":"request","seq":3}
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"line":13,"message":"Locations: 1","verified":true}]}}
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] --> {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4}
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":4,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] --> {"command":"setDataBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":5}
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":5,"success":true,"command":"setDataBreakpoints","body":{"breakpoints":[]}}
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] --> {"command":"setExceptionBreakpoints","arguments":{"filters":["cpp_throw"]},"type":"request","seq":6}
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":6,"success":true,"command":"setExceptionBreakpoints"}
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] --> {"command":"configurationDone","type":"request","seq":7}
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":7,"success":true,"command":"configurationDone"}
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":4,"event":"output","body":{"output":"Executing script: processCreateCommands\n"}}
[2020-12-22T14:42:58Z DEBUG codelldb::dap_codec] --> {"command":"threads","type":"request","seq":8}
[2020-12-22T14:42:59Z DEBUG codelldb::debug_session] process launch --stop-at-entry -> Failed, Error:  Fail
Error Message:
error: failed to get reply to handshake packet

[2020-12-22T14:42:59Z ERROR codelldb::debug_session] error: failed to get reply to handshake packet

[2020-12-22T14:42:59Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":5,"event":"output","body":{"category":"stderr","output":"error: failed to get reply to handshake packet\n\n"}}
[2020-12-22T14:42:59Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":2,"success":false,"message":"error: failed to get reply to handshake packet\n","show_user":true}
[2020-12-22T14:42:59Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":8,"success":true,"command":"threads","body":{"threads":[]}}
[2020-12-22T14:42:59Z DEBUG codelldb::dap_codec] --> {"command":"disconnect","arguments":{"restart":false},"type":"request","seq":9}
[2020-12-22T14:42:59Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":9,"success":true,"command":"disconnect"}
[2020-12-22T14:42:59Z DEBUG codelldb::dap_session] Client has disconnected
[2020-12-22T14:42:59Z DEBUG codelldb::debug_session] End of the requests stream
[2020-12-22T14:42:59Z DEBUG codelldb::debug_session] DebugSession::drop()
[2020-12-22T14:42:59Z DEBUG codelldb] Session has ended
[2020-12-22T14:42:59Z DEBUG codelldb] Exiting
Debug adapter exit code=0, signal=null.

Arm Rust x86 Vscode
configuration: {
  type: 'lldb',
  request: 'launch',
  name: 'Custom launch',
  preLaunchTask: 'cbuild',
  targetCreateCommands: [
    'target create --arch arm64-apple-macosx11.0.0 target/debug/day11'
  ],
  processCreateCommands: [ 'process launch --stop-at-entry' ],
  __configurationTarget: 5,
  custom: true,
  relativePathBase: '/Users/user/Documents/git/coding-advent-2020/day11'
}
liblldb: /Users/user/.vscode/extensions/vadimcn.vscode-lldb-1.6.0/lldb/lib/liblldb.dylib
environment: {
  LLDB_DEBUGSERVER_PATH: '/Users/user/llvm-project/build/bin/lldb-server'
}
params: {}
Listening on port 57146
[2020-12-22T14:49:57Z DEBUG codelldb] New debug session
INFO(Python) 15:49:58 formatters: Initializing
INFO(Python) 15:49:58 formatters.rust: Initializing
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] --> {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"lldb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us","supportsProgressReporting":true,"supportsInvalidatedEvent":true},"type":"request","seq":1}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":1,"success":true,"command":"initialize","body":{"exceptionBreakpointFilters":[{"default":true,"filter":"cpp_throw","label":"C++: on throw"},{"default":false,"filter":"cpp_catch","label":"C++: on catch"}],"supportTerminateDebuggee":true,"supportsCancelRequest":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsEvaluateForHovers":true,"supportsFunctionBreakpoints":true,"supportsGotoTargetsRequest":true,"supportsHitConditionalBreakpoints":true,"supportsLogPoints":true,"supportsReadMemoryRequest":true,"supportsRestartFrame":true,"supportsSetVariable":true}}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] --> {"command":"launch","arguments":{"type":"lldb","request":"launch","name":"Custom launch","preLaunchTask":"cbuild","targetCreateCommands":["target create --arch arm64-apple-macosx11.0.0 target/debug/day11"],"processCreateCommands":["process launch --stop-at-entry"],"__configurationTarget":5,"custom":true,"relativePathBase":"/Users/user/Documents/git/coding-advent-2020/day11","_adapterSettings":{"displayFormat":"auto","showDisassembly":"auto","dereferencePointers":true,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null,"terminalPromptClear":null},"__sessionId":"c71684c8-77d4-4f2d-a75b-2136fb7a6c58"},"type":"request","seq":2}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":1,"event":"output","body":{"output":"Executing script: targetCreateCommands\n"}}
[2020-12-22T14:49:58Z DEBUG codelldb::debug_session] target create --arch arm64-apple-macosx11.0.0 target/debug/day11 -> SuccessFinishNoResult, Error:  Success
Output Message:
Current executable set to '/Users/user/Documents/git/coding-advent-2020/day11/target/debug/day11' (arm64).

[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":2,"event":"output","body":{"output":"Current executable set to '/Users/user/Documents/git/coding-advent-2020/day11/target/debug/day11' (arm64).\n\n"}}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":3,"event":"initialized"}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints","arguments":{"source":{"name":"main.rs","path":"/Users/user/Documents/git/coding-advent-2020/day11/src/main.rs"},"lines":[13],"breakpoints":[{"line":13}],"sourceModified":false},"type":"request","seq":3}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"line":13,"message":"Locations: 1","verified":true}]}}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] --> {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":4,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] --> {"command":"setDataBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":5}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":5,"success":true,"command":"setDataBreakpoints","body":{"breakpoints":[]}}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] --> {"command":"setExceptionBreakpoints","arguments":{"filters":["cpp_throw"]},"type":"request","seq":6}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":6,"success":true,"command":"setExceptionBreakpoints"}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] --> {"command":"configurationDone","type":"request","seq":7}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":7,"success":true,"command":"configurationDone"}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":4,"event":"output","body":{"output":"Executing script: processCreateCommands\n"}}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] --> {"command":"threads","type":"request","seq":8}
[2020-12-22T14:49:58Z DEBUG codelldb::debug_session] process launch --stop-at-entry -> Failed, Error:  Fail
Error Message:
error: failed to get reply to handshake packet

[2020-12-22T14:49:58Z ERROR codelldb::debug_session] error: failed to get reply to handshake packet

[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":5,"event":"output","body":{"category":"stderr","output":"error: failed to get reply to handshake packet\n\n"}}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":2,"success":false,"message":"error: failed to get reply to handshake packet\n","show_user":true}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":8,"success":true,"command":"threads","body":{"threads":[]}}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] --> {"command":"disconnect","arguments":{"restart":false},"type":"request","seq":9}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":9,"success":true,"command":"disconnect"}
[2020-12-22T14:49:58Z DEBUG codelldb::dap_session] Client has disconnected
[2020-12-22T14:49:58Z DEBUG codelldb::debug_session] End of the requests stream
[2020-12-22T14:49:58Z DEBUG codelldb::debug_session] DebugSession::drop()
[2020-12-22T14:49:58Z DEBUG codelldb] Session has ended
[2020-12-22T14:49:58Z DEBUG codelldb] Exiting
Debug adapter exit code=0, signal=null.

@dguerri

Alternatively, or at the same time, we could give more evidence to these instructions... After all this is only going to work on Exploration, for now, so it's gong to be aimed to those who feel adventurous. With prebuild package

Insider is on Arm
https://code.visualstudio.com/insiders/
the ARM64 zip under the big download button
I only have Insider ARM version and it does not work. Maybe you really need exploratory
Error: "\"dlopen(/Users/user/.vscode-insiders/extensions/vadimcn.vscode-lldb-1.6.0-dev.2012211644/lldb/lib/liblldb.12.0.0git.dylib, 9): no suitable image found.  Did find:\\n\\t/Users/user/.vscode-insiders/extensions/vadimcn.vscode-lldb-1.6.0-dev.2012211644/lldb/lib/liblldb.12.0.0git.dylib: mach-o, but wrong architecture\\n\\t/Users/user/.vscode-insiders/extensions/vadimcn.vscode-lldb-1.6.0-dev.2012211644/lldb/lib/liblldb.12.0.0git.dylib: stat() failed with errno=102\""

make vsix_full

needs x86 Rust which is confusing too me
error[E0463]: can't find crate for `core`
|
= note: the `x86_64-apple-darwin` target may not be installed

Prebuild does also not work on insider
Error: "\"dlopen(/Users/user/.vscode-insiders/extensions/vadimcn.vscode-lldb-1.6.0-dev.2012192238/lldb/lib/liblldb.12.0.0git.dylib, 9): Library not loaded: /opt/local/lib/libform.6.dylib\\n  Referenced from: /Users/user/.vscode-insiders/extensions/vadimcn.vscode-lldb-1.6.0-dev.2012192238/lldb/lib/liblldb.12.0.0git.dylib\\n  Reason: image not found\""

At this point I am also confused in which version I should test it in Arm or Native, but only maybe because I tested so much 😅

@KulSthl I assume you are using my PR, totally forgot to mention it in the guide 😅
Will try insider later tonight!

make vsix_full

needs x86 Rust which is confusing too me

This shouldn't be.
I think Rosetta kicked in at some point.
Are you using Macports or Homebrew?

Prebuild does also not work on insider

Error: ""dlopen(/Users/user/.vscode-insiders/extensions/vadimcn.vscode-lldb-1.6.0-dev.2012192238/lldb/lib/liblldb.12.0.0git.dylib, 9): Library not loaded: /opt/local/lib/libform.6.dylib\n  Referenced from: /Users/user/.vscode-insiders/extensions/vadimcn.vscode-lldb-1.6.0-dev.2012192238/lldb/lib/liblldb.12.0.0git.dylib\n  Reason: image not found""

Can you please check whether the lib is actually there?

At this point I am also confused in which version I should test

Sorry about that 😅
If you have the chance it'd be great to make a test with Exploratory :)

Ah yeah,

/opt/local/lib/libform.6.dylib

This is because I am not sure how to build a self contained environment... will have to use  otool and follow dependencies...
In the meanwhile, please try to install the dependencies via MacPorts, by hand, as long as it fails to load.

I assume you are using my PR

could you elaborate

Are you using Macports or Homebrew?
I think Rosetta kicked in at some point.

Homebrew ARM and Homebrew x86 so could be

https://github.com/vadimcn/vscode-lldb/issues/397#issuecomment-749556362
As this looks promising I think I wait till @vadimcn has time to investigate

I assume you are using my PR

could you elaborate

I made some adjustments to allow building from source in this PR: https://github.com/vadimcn/vscode-lldb/pull/401

Are you using Macports or Homebrew?

I think Rosetta kicked in at some point.

Homebrew ARM and Homebrew x86 so could be

Homebrew ARM should do, but the dependencies will all be in a different location, so the prebuilt version won't work.
I will provide another package later :)

@KulSthl, I think I managed to get a self-contained lldb in this package.
Basically, I made a quick script to recursively enumerate dylibs of each binary and dylibs, copied it inside the lib/ directory and then run install_name_tool -change ... to relocate the dependencies.
I am pretty sure this is not a clean solution, and I see that the official releases for x86_64 don't depend on libncurses, to name one... Maybe there are some options I can pass to make when building project-llvm...
Anyway, I tested the attached vsix on Insiders (thanks @KulSthl! I didn't notice MS released an ARM64 version for Mac).
I removed my /opt/local/lib directory (it's used by Macport) and everything worked.
If you are willing to give it a go, I would like to know if it worked for you.

@KulSthl: Thanks for running these tests!   Unfortunately, I can't figure out from these logs what is going on there :(
To clarify what configuration I had in mind:

VSCode: can be either x86 or arm64 - the latter is probably preferable, since it's native on that platform
Rust compilation target: arm64.
Codelldb - x86, running via Rosetta.
debugserver (if you override it): arm64, and I would try to use the one from xcode's lldb (i.e. the one you install with xcode-select --install)

Why did you use target create --arch arm64-apple-macosx11.0.0 ... rather than target create --arch aarch64 ...?   AFAIK, LLVM calls this architecture "aarch64".

To clarify what configuration I had in mind

That should work.
I don't have my laptop right now, but one possible issue is that binaries in Big Sur are universal right now, and so is debugserver (need to double check, but I am fairly sure).
So, if debugserver is started from a x86 process, will be emulated.
I see code-lldb ships with its own debugserver, so we need to use the system one and we need to make sure it's started in native mode.

Running lldb and debug server on the CLI, in the configuration suggested by @vadimcn:

seems to work well :)

Why did you use target create --arch arm64-apple-macosx11.0.0 ... rather than target create --arch aarch64 ...? AFAIK, LLVM calls this architecture "aarch64".

Because it said I should use this instead

Why did you use target create --arch arm64-apple-macosx11.0.0 ... rather than target create --arch aarch64 ...? AFAIK, LLVM calls this architecture "aarch64".

Because it said I should use this instead

I think you ended up with a binary for x86 (the one to be debugged, in day11)

It depends with my rust version if I compile it with x86 this message pops up and with arm vice versa

@dguerri https://github.com/vadimcn/vscode-lldb/issues/397#issuecomment-749810022
is working without a problem on my machine

On current default x86 VScode it is working with Rust x86 and fails with Rust ARM

Although this is expected, you made me think about a possible use case I didn’t consider before.
@vadimcn, this is really interesting as x86 and arm are going to coexist form some time and maybe they should both be supported (within code-lldb)... what’s your take on this?

I made a mistake. My settings were not on default
{
    "lldb.library": "/Library/Developer/CommandLineTools/Library/PrivateFrameworks/LLDB.framework/Versions/A/LLDB"
}

activates x86 debugging
on vscode insider and vscode

This is really interesting as x86 and arm are going to coexist form some time and maybe they should both be supported (within code-lldb)... what’s your take on this?

Sure, I'm all for it, but we need to figure out how this would work.   For example, I am not sure how Rosetta presents emulated x86 binaries to the debugger: as arm instructions or as original x86 instructions?   In the former case - does it also translate the debug info?   This will also need special handling in the debugger, as the executable file will be of the wrong architecture.

With @dguerri's share file and   @KulSthl's config suggest. it worked for me , thanks .

rustc 1.51.0-nightly (e22670468 2020-12-30) with Rustup 1.23.1 install

M1 macbook with x86 vscode and x86 rust. @KulSthl 's settings worked for me. Thanks!

M1 macbook with x86 vscode and x86 rust. @KulSthl 's settings worked for me. Thanks!

Is working without a problem on ARM VScode insider with Rust x86 and Rust ARM

Great!
Note, though, that if you load a system LLDB backend via "lldb.library", it won't have Rust-specific support code.  As a result, you may notice problems with visualization of some data types (such as  enums).

Is working without a problem on ARM VScode insider with Rust x86 and Rust ARM

Great!
Note, though, that if you load a system LLDB backend via "lldb.library", it won't have Rust-specific support code.  As a result, you may notice problems with visualization of some data types (such as  enums).

Hey! I've run into this issue as well. I installed VSCode stable today as well as CodeLLDB (and rust-analyzer). What's the path to resolution and can I help us get there?

Hey! I've run into this issue as well. I installed VSCode stable today as well as CodeLLDB (and rust-analyzer). What's the path to resolution and can I help us get there?

Also, might I suggest we label this confirmed rather than simply enhancement. The issue presents as a bug and is rather confusing to make sense of for a newcomer (to these tools and this project).

Also, might I suggest we label this confirmed rather than simply enhancement. The issue presents as a bug and is rather confusing to make sense of for a newcomer (to these tools and this project).

Hi @dcow, from my perspective this is not a bug.
M1 is an additional platform this project could officially support one day.
If you want to debug stuff on Darwin ARM64 right now, you can follow the guide I wrote in a comment above while using my PR to compile vscode-lldb (and llvm) from source.
Alternatively, you can use the vsix package I have prepared. It's linked in a comment above.
In both cases, you need to use vscode insiders.
Keep in mind that you will loose the ability to debug x86 code and that heap dump is bugged for llvm on M1 apparently (see comments on my PR).
Cheers

Hi @dcow, from my perspective this is not a bug.
M1 is an additional platform this project could officially support one day.
If you want to debug stuff on Darwin ARM64 right now, you can follow the guide I wrote in a comment above while using my PR to compile vscode-lldb (and llvm) from source.
Alternatively, you can use the vsix package I have prepared. It's linked in a comment above.
In both cases, you need to use vscode insiders.
Keep in mind that you will loose the ability to debug x86 code and that heap dump is bugged for llvm on M1 apparently (see comments on my PR).
Cheers

M1 is an additional platform this project could officially support one day.

Perhaps then a blurb in the README is in order linking this issue. I spent a large amount of time trying to figure out why my setup does not work after following instructions and being presented with:
process exited with status -1 (Error 1)

I even posted to the mailing list. Nothing indicated this was an issue with the instruction set that my processor uses. If it's not a bug then it would be helpful if it was made clear to newcomers that this extension only works for debugging x86 binaries at the moment (set expectations).
@dguerri I'll take a look at your stuff. Part of why I asked is because I don't want to use your stop-gap if a resolution for this issue is in progress and will be landing soon. I can wait a little while for things to come around so also just curious how close we are since this thread went silent for a few weeks other than people affirming their success using the workaround.

The additional context in https://github.com/vadimcn/vscode-lldb/pull/401 is helpful!

@dcow For what it's worth, I ran into the same exact issue. I tried both Visual Studio Code and the VS Code Insiders edition, I saw this reddit thread indicating that that might make it work but to no avail.

@dcow For what it's worth, I ran into the same exact issue. I tried both Visual Studio Code and the VS Code Insiders edition, I saw this reddit thread indicating that that might make it work but to no avail.

@adamnemecek @dcow
Hi rust arm-darwin is now stable. So you have as a default native rust installed now. But the extension does not provide support for native m1.
run this command
 rustup default stable-x86_64-apple-darwin

start your intel vscode add the alternate backend in the workspace you need it
and start debugging
for the unofficial custom extension to work https://github.com/vadimcn/vscode-lldb/issues/397#issuecomment-749810022 (best performing)
use insider arm vscode
install the default toolchain
 rustup default stable-aarch64-apple-darwin

and ideally do not use alternate backend (look at .vscode/settings.json and remove the "lldb.library" line)

@adamnemecek @dcow
Hi rust arm-darwin is now stable. So you have as a default native rust installed now. But the extension does not provide support for native m1.
run this command
 rustup default stable-x86_64-apple-darwin

start your intel vscode add the alternate backend in the workspace you need it
and start debugging
for the unofficial custom extension to work https://github.com/vadimcn/vscode-lldb/issues/397#issuecomment-749810022 (best performing)
use insider arm vscode
install the default toolchain
 rustup default stable-aarch64-apple-darwin

and ideally do not use alternate backend (look at .vscode/settings.json and remove the "lldb.library" line)

@KulSthl that worked! i can't believe i missed the vsix file. thanks so much!

@KulSthl that worked! i can't believe i missed the vsix file. thanks so much!

@KulSthl yeah I have the native rust toolchain installed. Building and everything works fine in VSCode. Mostly concerned here with tracking the work to get native debugging working with this plugin. I'm willing to wait for things to resolve if it means I don't need a workaround.

@KulSthl yeah I have the native rust toolchain installed. Building and everything works fine in VSCode. Mostly concerned here with tracking the work to get native debugging working with this plugin. I'm willing to wait for things to resolve if it means I don't need a workaround.

Build and install vscode-lldb for M1 (aarch64 native)
Official building instructions:
https://github.com/vadimcn/vscode-lldb/blob/master/BUILDING.md
Prerequisites
You will need VSCode Exploratory as M1 is still not supported by VSCode Insider or Stable.
Install Xcode tools
xcode-select --install

Install Rust
Rust (rustup) stable is still not available on M1. This will change soon, but for now, see this thread rust-lang/rustup#2413
Install Macports
I use Macports, I think Homebrew (native for M1) should work too, bit in this guide I am assuming you bave Macports installed.
https://www.macports.org
[optional] ccache
At this stage, if you want native stuff for your Mac, chances are that you are going to build (and rebuild) a lot of stuff.
So, I recommend installing ccache.
Of course, this is not going to save you time for llvm (see below), at least the first time.
llvm and vscode-lldb dependecies
sudo port install cmake nodejs15 npm6

Building stuff
build llvm
git clone https://github.com/llvm/llvm-project.git
cd llvm-project ; mkdir build ; cd build
cmake ../llvm -DLLVM_ENABLE_PROJECTS="clang;libcxx;lldb"
make lldb lldb-server

That is going to take a while.
create a zip with llvm
cd lldb
zip -r lldb-m1.zip bin/ lib/liblldb.12.0.0git.dylib lib/liblldb.dylib

The content of the archive will be used by vscode-lldb later.
Note that the content of lldb-m1.zip will probably only work on your local machine as a lot of other dependencies are left outside (e.g. debugserver and required libs).
building vscode-lldb
git clone https://github.com/vadimcn/vscode-lldb.git
cd vscode-lldb
git submodule update --init --recursive
npm install
mkdir build ; cd build
mkdir lldb
mv <location of lldb-m1.zip you create belore> lldb/
LLDB_PACKAGE=./lldb-m1.zip cmake ..
make vsix_full

If everything goes well:
mv codelldb-full.vsix codelldb-aarch64-darwin.vsix

Install the official vscode-lldb extension and reload.
Install codelldb-aarch64-darwin.vsix via "Install from VSIX..." in the extension menu of VSCode Exploratory.

worked, thank you!

Build and install vscode-lldb for M1 (aarch64 native)
Official building instructions:
https://github.com/vadimcn/vscode-lldb/blob/master/BUILDING.md
Prerequisites
You will need VSCode Exploratory as M1 is still not supported by VSCode Insider or Stable.
Install Xcode tools
xcode-select --install

Install Rust
Rust (rustup) stable is still not available on M1. This will change soon, but for now, see this thread rust-lang/rustup#2413
Install Macports
I use Macports, I think Homebrew (native for M1) should work too, bit in this guide I am assuming you bave Macports installed.
https://www.macports.org
[optional] ccache
At this stage, if you want native stuff for your Mac, chances are that you are going to build (and rebuild) a lot of stuff.
So, I recommend installing ccache.
Of course, this is not going to save you time for llvm (see below), at least the first time.
llvm and vscode-lldb dependecies
sudo port install cmake nodejs15 npm6

Building stuff
build llvm
git clone https://github.com/llvm/llvm-project.git
cd llvm-project ; mkdir build ; cd build
cmake ../llvm -DLLVM_ENABLE_PROJECTS="clang;libcxx;lldb"
make lldb lldb-server

That is going to take a while.
create a zip with llvm
cd lldb
zip -r lldb-m1.zip bin/ lib/liblldb.12.0.0git.dylib lib/liblldb.dylib

The content of the archive will be used by vscode-lldb later.
Note that the content of lldb-m1.zip will probably only work on your local machine as a lot of other dependencies are left outside (e.g. debugserver and required libs).
building vscode-lldb
git clone https://github.com/vadimcn/vscode-lldb.git
cd vscode-lldb
git submodule update --init --recursive
npm install
mkdir build ; cd build
mkdir lldb
mv <location of lldb-m1.zip you create belore> lldb/
LLDB_PACKAGE=./lldb-m1.zip cmake ..
make vsix_full

If everything goes well:
mv codelldb-full.vsix codelldb-aarch64-darwin.vsix

Install the official vscode-lldb extension and reload.
Install codelldb-aarch64-darwin.vsix via "Install from VSIX..." in the extension menu of VSCode Exploratory.

worked, thank you!

Thanks @dguerri for the rundown of installation instructions. I ran through them, skipping the rust step (since I am not working in rust, but C++); llvm build seemed to work OK, but then when I got to this bit :

create a zip with llvm
cd lldb
zip -r lldb-m1.zip bin/ lib/liblldb.12.0.0git.dylib lib/liblldb.dylib

% cd lldb
cd: no such file or directory: lldb
% find . -name "*git.dylib"
./lib/liblldb.13.0.0git.dylib

So this seems like the llvm build either did not work properly, or the version change has meant that it produces a different folder structure than expected. If I modify the zip command to nominate the 13.0.0git.dylib file instead, it seems to work:
% zip -r lldb-m1.zip bin/ lib/liblldb.13.0.0git.dylib lib/liblldb.dylib
adding: bin/ (stored 0%)
adding: bin/lldb-dotest (deflated 65%)
adding: bin/lldb (deflated 81%)
adding: bin/lldb-argdumper (deflated 81%)
adding: bin/clang-tblgen (deflated 83%)
adding: bin/lldb-server (deflated 83%)
adding: bin/lldb-repro (deflated 60%)
adding: bin/lldb-tblgen (deflated 82%)
adding: bin/llvm-tblgen (deflated 84%)
adding: bin/llvm-lit (deflated 68%)
adding: lib/liblldb.13.0.0git.dylib (deflated 83%)
adding: lib/liblldb.dylib (deflated 83%)

So now into the next bit, marching hopefully uphill :

building vscode-lldb
git clone https://github.com/vadimcn/vscode-lldb.git
cd vscode-lldb
git submodule update --init --recursive
npm install
mkdir build ; cd build
mkdir lldb
mv <location of lldb-m1.zip you create belore> lldb/
LLDB_PACKAGE=./lldb-m1.zip cmake ..
make vsix_full

Start out with the git-clone, which seems to work (I was dubious at doing it in this folder, but went ahead anyway) :
% git clone https://github.com/vadimcn/vscode-lldb.git
Cloning into 'vscode-lldb'...
remote: Enumerating objects: 174, done.
remote: Counting objects: 100% (174/174), done.
remote: Compressing objects: 100% (94/94), done.
remote: Total 5632 (delta 89), reused 121 (delta 76), pack-reused 5458
Receiving objects: 100% (5632/5632), 2.79 MiB | 2.50 MiB/s, done.
Resolving deltas: 100% (3776/3776), done.

Then the submodule and npm install :
% cd vscode-lldb
asnaroo@asnaroos-MacBook-Air vscode-lldb % git submodule update --init --recursive
Submodule 'schemafy' (https://github.com/vadimcn/schemafy.git) registered for path 'adapter/deps/schemafy'
Cloning into '/Users/asnaroo/Desktop/llvm/llvm-project/build/vscode-lldb/adapter/deps/schemafy'...
Submodule path 'adapter/deps/schemafy': checked out '0ec75f5cf7c63f462f1e003bfec06b5dac0483dc'
Submodule 'tests/JSON-Schema-Test-Suite' (https://github.com/json-schema-org/JSON-Schema-Test-Suite) registered for path 'adapter/deps/schemafy/tests/JSON-Schema-Test-Suite'
Cloning into '/Users/asnaroo/Desktop/llvm/llvm-project/build/vscode-lldb/adapter/deps/schemafy/tests/JSON-Schema-Test-Suite'...
Submodule path 'adapter/deps/schemafy/tests/JSON-Schema-Test-Suite': checked out '689d2f28182720d3778ca91c149f725a6ce73f71'

% npm install
npm WARN Invalid version: "@VERSION@"
npm WARN vscode-lldb No description
npm WARN vscode-lldb No repository field.
npm WARN vscode-lldb No README data
npm WARN vscode-lldb No license field.

added 37 packages from 27 contributors in 1.272s

12 packages are looking for funding
run `npm fund` for details

found 0 vulnerabilities

% mkdir build
% cd build
% mkdir lldb
% mv ../../lldb-m1.zip lldb/

So now to the cmake (I'd thought this next line should be split into two, but it seems to work as one line, so ¯\(ツ)/¯ ). I've included all the console spew for clues, but it certainly seems like not everything is happy :
% LLDB_PACKAGE=./lldb-m1.zip cmake ..
-- The C compiler identification is AppleClang <IP_ADDRESS>00032
-- The CXX compiler identification is AppleClang <IP_ADDRESS>00032
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
Version 1.6.1-dev.2102020642
Using LLDB_PACKAGE=./lldb-m1.zip
-- Found Python3: /usr/local/Frameworks/Python.framework/Versions/3.9/bin/python3.9 (found version "3.9.1") found components: Interpreter
npm WARN deprecated<EMAIL_ADDRESS>Debug versions >=3.2.0 <3.2.7 || >=4 <4.3.1 have a low-severity ReDos regression when used in a Node.js environment. It is recommended you upgrade to 3.2.7 or 4.3.1. (https://github.com/visionmedia/debug/issues/797)
npm WARN deprecated<EMAIL_ADDRESS>"Please update to latest v2.3 or v2.2"
npm WARN deprecated<EMAIL_ADDRESS>Use cheerio-select instead
npm WARN deprecated<EMAIL_ADDRESS>Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies.
npm WARN deprecated<EMAIL_ADDRESS>https://github.com/lydell/resolve-url#deprecated
npm WARN deprecated<EMAIL_ADDRESS>Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated<EMAIL_ADDRESS>fsevents 1 will break on node v14+ and could be using insecure binaries. Upgrade to fsevents 2.

><EMAIL_ADDRESS>install /Users/asnaroo/Desktop/llvm/llvm-project/build/vscode-lldb/build/node_modules/watchpack-chokidar2/node_modules/fsevents
> node install.js

  SOLINK_MODULE(target) Release/.node
ld: library not found for -lc++
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Release/.node] Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/opt/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:194:23)
gyp ERR! stack     at ChildProcess.emit (node:events:379:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (node:internal/child_process:289:12)
gyp ERR! System Darwin 20.2.0
gyp ERR! command "/opt/local/bin/node" "/opt/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/asnaroo/Desktop/llvm/llvm-project/build/vscode-lldb/build/node_modules/watchpack-chokidar2/node_modules/fsevents
gyp ERR! node -v v15.7.0
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok
added 575 packages from 316 contributors and audited 575 packages in 9.255s

36 packages are looking for funding
  run `npm fund` for details

found 2 low severity vulnerabilities
  run `npm audit fix` to fix them, or `npm audit` for details
-- The C compiler identification is AppleClang <IP_ADDRESS>00032
-- The CXX compiler identification is AppleClang <IP_ADDRESS>00032
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/asnaroo/Desktop/llvm/llvm-project/build/vscode-lldb/build/debuggee
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build

Despite the errors, it claims to have done something successfully, so on to the final step, which unfortunately fails definitively :
% make vsix_full
Scanning dependencies of target lldb
Archive:  ./lldb-m1.zip
   creating: /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/lldb/bin/
  inflating: /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/lldb/bin/lldb-dotest
  inflating: /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/lldb/bin/lldb
  inflating: /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/lldb/bin/lldb-argdumper
  inflating: /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/lldb/bin/clang-tblgen
  inflating: /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/lldb/bin/lldb-server
  inflating: /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/lldb/bin/lldb-repro
  inflating: /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/lldb/bin/lldb-tblgen
  inflating: /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/lldb/bin/llvm-tblgen
  inflating: /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/lldb/bin/llvm-lit
  inflating: /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/lldb/lib/liblldb.13.0.0git.dylib
  inflating: /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/lldb/lib/liblldb.dylib
[  0%] Built target lldb
Scanning dependencies of target extension

><EMAIL_ADDRESS>webpack /Users/asnaroo/Desktop/llvm/llvm-project/build/vscode-lldb/build
> webpack "--display=minimal" "--mode=development" "--output=/Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/extension.js" "/Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/extension/main.ts"

   39 modules
[  0%] Built target extension
Scanning dependencies of target formatters
[  7%] Copying /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/formatters/__init__.py to /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/formatters/__init__.py
[ 14%] Copying /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/formatters/rust.py to /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/formatters/rust.py
[ 14%] Built target formatters
Scanning dependencies of target codelldb_lib
[ 21%] Copying /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/adapter/console.py to /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/adapter/console.py
[ 28%] Copying /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/adapter/codelldb.py to /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/adapter/codelldb.py
[ 35%] Copying /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/adapter/value.py to /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/adapter/value.py
[ 42%] Copying /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/adapter/debugger.py to /Users/asnaroo/desktop/llvm/llvm-project/build/vscode-lldb/build/adapter/debugger.py
[ 50%] Building codelldb_lib
No such file or directory
make[3]: *** [adapter/CMakeFiles/codelldb_lib] Error 1
make[2]: *** [adapter/CMakeFiles/codelldb_lib.dir/all] Error 2
make[1]: *** [CMakeFiles/vsix_full.dir/rule] Error 2
make: *** [vsix_full] Error 2

So (as something of a newbie in this domain) I am stumped as to what my next step should be. I would deeply appreciate any pointers, as I'd love to get vscode-lldb running on my lovely new M1 macbook air. Apologies for the profuse console spam in this message, but I figured better to supply the context rather than potentially elide crucial information.
Many thanks in advance. If I can be of use in helping others to go down this path more smoothly, I hereby volunteer.

Trying again today : repeated the above, but installed rustup as per instructions beforehand, and cleaned out / rebuilt llvm etc. Just in case.
LLDB_PACKAGE=./lldb-m1.zip cmake ..

still reports
SOLINK_MODULE(target) Release/.node
ld: library not found for -lc++
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Release/.node] Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit    (/opt/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:194:23)
gyp ERR! stack     at ChildProcess.emit (node:events:378:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12)
gyp ERR! System Darwin 20.2.0
gyp ERR! command "/opt/local/bin/node" "/opt/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/asnaroo/Desktop/llvm/llvm-project/build/vscode-lldb/build/node_modules/watchpack-chokidar2/node_modules/fsevents
gyp ERR! node -v v15.8.0
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok

Following which,
make vsix_full

Fails with a different error than last time :
Compiling log v0.4.11
error[E0463]: can't find crate for `core`
  |
  = note: the `x86_64-apple-darwin` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: could not compile `lazy_static`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error[E0463]: can't find crate for `core`
  |
  = note: the `x86_64-apple-darwin` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error[E0463]: can't find crate for `std`
  |
  = note: the `x86_64-apple-darwin` target may not be installed

error[E0463]: can't find crate for `std`
  |
  = note: the `x86_64-apple-darwin` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: build failed
make[3]: *** [adapter/CMakeFiles/codelldb_lib] Error 101
make[2]: *** [adapter/CMakeFiles/codelldb_lib.dir/all] Error 2
make[1]: *** [CMakeFiles/vsix_full.dir/rule] Error 2
make: *** [vsix_full] Error 2

I'll keep digging, but if anyone has some science to drop on me, it would be much appreciated :-)

So I got  access to an M1 machine and did some digging.   As I suspected, the architecture of CodeLLDB process itself isn't that important, the only bit that really needs to be native is the debugserver.  Unfortunately, some assumptions about process' own arch had crept into LLDB code, so things don't work out of the box as they should.   To summarize my findings:

It is possible to debug x86 binaries using existing extension - as long as one uses Rosetta debugserver:

Download and install the x86 version,
Add "adapterEnv": { "LLDB_DEBUGSERVER_PATH": "/Library/Apple/usr/libexec/oah/debugserver" } into workspace configuration.

Debugging aarch64 binaries is also possible, but a bit more complicated:

After installing the extension, switch to the system liblldb backend.  Alas, doing so will degrade Rust debugging experience somewhat and you might not be able to see  contents of some enum variables.
Create a shell script containing arch -arch arm64e /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/debugserver "$@", and make it executable (chmod +x <script>).
Add "adapterEnv": { "LLDB_DEBUGSERVER_PATH": "<path to the above script>" } into workspace configuration.

Debugging aarch64 binaries is also possible, but a bit more complicated

This worked, thanks ! Back in the saddle ᕦ(ツ)ᕤ

So I got  access to an M1 machine and did some digging.   As I suspected, the architecture of CodeLLDB process itself isn't that important

Fantastic!
I really like this solution as you can switch between one or the other architecture, which sounds terribly useful :)
I think we should be able to make it completely transparent by detecting the target architecture before starting the "right" debugserver.
In time when apple silicon is supported by CI/CD pipelines, both (patched) debugservers can be included in the vsix, maybe.

@asnar00
If you have not yet solved this issue... to run make vsix_full add compile target first.
rustup target add x86_64-apple-darwin

Thought that might be helpful here. Still have not gone the full path. But one step closer. 😋

I was facing the same issue @KulSthl suggestion adding lldb.library in setting.json helped me thank you.

@vadimcn

Add "adapterEnv": { "LLDB_DEBUGSERVER_PATH": "<path to the above script>" } into workspace configuration.

I had to use "lldb.adapterEnv" instead of just adapterEnv but it worked just fine with that tweak!

Trying again today : repeated the above, but installed rustup as per instructions beforehand, and cleaned out / rebuilt llvm etc. Just in case.
LLDB_PACKAGE=./lldb-m1.zip cmake ..

still reports
SOLINK_MODULE(target) Release/.node
ld: library not found for -lc++
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Release/.node] Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit    (/opt/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:194:23)
gyp ERR! stack     at ChildProcess.emit (node:events:378:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12)
gyp ERR! System Darwin 20.2.0
gyp ERR! command "/opt/local/bin/node" "/opt/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/asnaroo/Desktop/llvm/llvm-project/build/vscode-lldb/build/node_modules/watchpack-chokidar2/node_modules/fsevents
gyp ERR! node -v v15.8.0
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok

Following which,
make vsix_full

Fails with a different error than last time :
Compiling log v0.4.11
error[E0463]: can't find crate for `core`
  |
  = note: the `x86_64-apple-darwin` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: could not compile `lazy_static`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error[E0463]: can't find crate for `core`
  |
  = note: the `x86_64-apple-darwin` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error[E0463]: can't find crate for `std`
  |
  = note: the `x86_64-apple-darwin` target may not be installed

error[E0463]: can't find crate for `std`
  |
  = note: the `x86_64-apple-darwin` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: build failed
make[3]: *** [adapter/CMakeFiles/codelldb_lib] Error 101
make[2]: *** [adapter/CMakeFiles/codelldb_lib.dir/all] Error 2
make[1]: *** [CMakeFiles/vsix_full.dir/rule] Error 2
make: *** [vsix_full] Error 2

I'll keep digging, but if anyone has some science to drop on me, it would be much appreciated :-)

bro, Have you solved the problem

I had to use "lldb.adapterEnv" instead of just adapterEnv

Yes, it was supposed to be "lldb.adapterEnv".  Thanks for catching that!
Updated my comment above and also copied to a wiki page.

I could reduce the file size, but I have no idea how to create a package which doesn't depend on my environment...
Anyway, this is it
https://www.icloud.com/iclouddrive/0lxZDEqpFo6d_J_rWgaI0cJug#codelldb-aarch64-darwin
Install it, in VSCode Exploratory, after installing the official extension, using the "install from VSIX" option.

I used this method, but it gave me an error.  ERROR: Unable to start debugging. Unexpected LLDB output from command "-exec-run". process exited with status -1 (attach failed ((os/kern) invalid argument))

Build and install vscode-lldb for M1 (aarch64 native)...

I executed these commands under M1 Mac mini with the newest VSCode Universe Edition.
And at the step of make vsix_full I got these error:
   Compiling cfg-if v0.1.10
error[E0463]: can't find crate for `std`
  |
  = note: the `x86_64-apple-darwin` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: could not compile `slab`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error[E0463]: can't find crate for `std`
  |
  = note: the `x86_64-apple-darwin` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error[E0463]: can't find crate for `core`
  |
  = note: the `x86_64-apple-darwin` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error[E0463]: can't find crate for `core`
  |
  = note: the `x86_64-apple-darwin` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: build failed
make[3]: *** [adapter/CMakeFiles/codelldb_lib] Error 101
make[2]: *** [adapter/CMakeFiles/codelldb_lib.dir/all] Error 2
make[1]: *** [CMakeFiles/vsix_full.dir/rule] Error 2
make: *** [vsix_full] Error 2

Due to that I have installed Rust. 1.50.0 aarch64-apple-darwin edition, I thought it was because there is no x86_64-apple-darwin rustc in my system and I thought switching this version in makefiles would work.
So I replaced x86_64-apple-darwin to aarch64-apple-darwin in CMakeLists.txt and azure-pipelines.yml. And it works well.

HI!
I have error "process exited with status -1 (attach failed ((os/kern) invalid argument))"
How it is fix?

@mefilt: for now, you'll need to use this workaround.

@vadimcn thx, I did all step instruction, but i have same error

I can confirm that the workaround works for me to debug C++ M1 native bins. All in latest stable M1 Visual Code (Apple arch). At first it didn't worked, but forgot to install the debugger extension mentioned in the workaround. So make sure you follow all those steps.

After adopting the workaround:
Exception has occurred.
EXEC_BAD_ACCESS.

I've created a native arm64 OSX package.  No idea if it works though. Anyone wanna test?

@vadimcn

I've created a native arm64 OSX package. No idea if it works though. Anyone wanna test?

I tried it out just now with Rust and VSCode Version: 1.55.0-insider Commit: 6ebe2a14f3722bc2582ecd8108d0a71dfdd46036
It works! 🎉
Thanks for figuring this out!
Some things don't seem to be formatted correctly (like Rust enums and Vecs), but I think that's expected?

@kettle11: Thanks!

Some things don't seem to be formatted correctly (like Rust enums and Vecs), but I think that's expected?

Not really...   There's no reason for it to work differently than the x86 version.   Could you be more specific about the problems you see?

A MemoryError???  I don't even...
Looks like I'll need to get my hands on an actual M1 Mac.    Anyone knows a hosted service that charges per-day?

A MemoryError??? I don't even...
Looks like I'll need to get my hands on an actual M1 Mac. Anyone knows a hosted service that charges per-day?

https://www.scaleway.com/en/hello-m1/ for 10 pence an hour.

I've created a native arm64 OSX package. No idea if it works though. Anyone wanna test?

I can confirm that this also apparently works to debug C++ compiled arm64. Will let you know if I spot any issues. Many thanks!

I've created a native arm64 OSX package. No idea if it works though. Anyone wanna test?

It works well on my Mac with M1.

Has anyone else given it a try? I thought there were tons of people who wanted M1 support 😉

This build also works for me! I'm debugging NIM code on M1 Mac. Thanks a lot!

I've created a native arm64 OSX package. No idea if it works though. Anyone wanna test?

Thanks, it works great on my m1 Mac.

I've created a native arm64 OSX package. No idea if it works though. Anyone wanna test?

Yay! Finally! Thanks!

I've created a native arm64 OSX package. No idea if it works though. Anyone wanna test?

Yay! Finally! Thanks!

How can I solve this problem， plz。 Warning: Debuggee TargetArchitecture not detected, assuming x86_64.
ERROR: Unable to start debugging. Unexpected LLDB output from command "-exec-run". process exited with status -1 (attach failed ((os/kern) invalid argument))

Has anyone else given it a try? I thought there were tons of people who wanted M1 support 😉

So far working great! I was running into lots of issues trying to do a proper build myself, so thanks a ton for doing this.

@WunschTxT:  This is not a message Codelldb produces.   Are you sure you've switched "type" to "lldb"?
Also, be sure to use  arm64 version of VSCode.  Otherwise, Codelldb runs into the same "process exited with status -1 (attach failed ((os/kern) invalid argument))" error.

Codelldb runs into the same "process exited with status -1 (attach failed ((os/kern) invalid argument))" error.

About that: Does anyone know how to switch the preferred architecture on OSX?   Looks like it still affects Codelldb's child processes, even though Codelldb itself is an arm64 process.

@vadimcn  In the case where type is LLDB, failed to get reply to handshake packet

@vadimcn
thank you evry much!

Works for me debugging Swift code on an M1 mac. TYVM!

Released another build.   Python should work now.

Released another build. Python should work now.

It works fine, vec and enum can be viewed

I've created a native arm64 OSX package. No idea if it works though. Anyone wanna test?

It works fine for me , Thanks !
OS: Mac OS 11.3 beta 5 big surf.
VS Code: Version: 1.55.0 (Universal),OS: Darwin arm64 20.4.0

Released another build. Python should work now.

Yes !
VS Code's debug-console doesn't report any error now .

Released another build. Python should work now.

Works great for me even removing the lldb.library and adapterEnv settings!

Works great for me even removing the lldb.library and adapterEnv settings!

Yes!  Everything added as a part of the earlier workaround should be removed now.

works on my system too. Thanks!!!

Released another build. Python should work now.

I downloaded the build and the python's problem was settled , but there're still some problems.When debugging ,there‘s a warning：“failed to get reply to handshake packet”.
Can you tell me what info else is needed?
VScode: Darwin arm64 1.55.1
OS: Mac OS 11.2.3  big sur

Released another build. Python should work now.

worked for me debugging Rust on an m1 MacBook without Rosetta turned on, awesome & thanks much!

@vadimcn Unfortunately I see this error:
process exited with status -1 (cannot attach to process due to System Integrity Protection)
Any idea how to fix that except turning off System Integrity Protection?

@tanvipotdar: sorry, never seen this one (outside of trying to attach to system binaries).

It seems to be broken-ish for me. Trying to debug C code, built for arm64 or x86_64 using the latest VSCode 1.55 which is built for Apple Silicon, so I guess I don't need an insider version, or do I?
Anyway, when I install your latest package @vadimcn, breakpoints are ignored, and when I stop the execution the source code map is not resolved, and I can only step over assembly instructions, but not source code. The lldb.ToggleDisassembly property doesn't make any difference. It seems it is not able to resolve the code map for some reason, and that's probably the same reason it ignores the breakpoints in the first instance.
Do you have any hint of what could be possibly going wrong here?

@fabiopolimeni: https://github.com/vadimcn/vscode-lldb/wiki/Debugging-problems#breakpoints-not-working

@vadimcn thank you. Adding -g explicitly as a compiler option fixed the source map. Although, I am not sure why building the project with cmake in Debug does produce debug symbols, but source files are not correctly picked up, and the source map solution didn't work. So, I've switched to plain clang -g this time with better luck. Thanks again for the help, and thank you for the plugin too.

Apple Silicon is now supported in v1.6.2.
Thanks for helping to test it!


AC is became UNAVAILABLE and connected again

Hi
I'm using this integration for a long time.
a couple of months ago the ACs started to have a strange behavior like going on and off in the HA panel. You can see this in the attached video.
That is causing problems with automations of course.
what could be wrong?

https://user-images.githubusercontent.com/17390016/117554469-a2d2b900-b060-11eb-8307-94a86e034f07.mp4

Same behavior here in my hass

Same here.

Same for me I get alerts like: "AC Day Zone state changed to: unavailable" and it recovers after few minutes.
Question is: is this related to this integration? Or it's something related with the USB dongle? Have anyone tried to remove/disable integration and see if it gets fixed?

I tried - no help.
The dongle is probably OK, the android app doesn't dhow any disconnection...
I hope the developer will make contact...
בתאריך יום ב׳, 7 ביוני 2021, 11:14, מאת msanchezt @.***

:

Same for me I get alerts like: "AC Day Zone state changed to: unavailable"
and it recovers after few minutes.
Question is: is this related to this integration? Or it's something
related with the USB dongle? Have anyone tried to remove/disable
integration and see if it gets fixed?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mac-zhou/midea-ac-py/issues/62#issuecomment-855707485,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEEVTQBXF4PEKEDG2WVXUFTTRR5U3ANCNFSM44OAP3TA
.

Are you sure about the android app not showing any disconnection? In my case, whenever I receive the "unavailable" state from Home Assistant I go straight to check the app and I see the device offline.
It gets resolved just by waiting few minutes, by power cycling the device or by rebooting the Access point (meaning forcing the device to reconnect to wifi).
Funny thing is that even the device shows "unavailable" on HA and "offline" on android App I can ping the IP of the device, meaning is connected to wifi still.
Very strange, and not sure how to do some more investigation

@msanchezt - THAT problem is a real problem. it is a problem with the dongle probably, and to solve it I do the same as you - power cycle the device and it is alive again. that problem was always with the Midea AC...
The problem this ticket is referring is HA problem, as you can see in the video - the ACs are toggling  from online to unavailable all of the time.
anyway, until @mac-zhou will check and fix it, I solved it by going back to the former integration I worked with (through the Midea cloud) and it works flawlessly.

https://github.com/andersonshatch/midea-ac-py
the configuration is as the following:
climate:
      platform: midea
      app_key: 3742e9e5842d4ad59c2db887e12449f9
      username: !secret midea_user
      password: !secret midea_pass

The reason for this problem is that midea-msmart(version 0.1.24) use the dongle response as the AC's status.
Sometimes the dongle does not respond.
you can add scan_interval: 60 to configure file and see if it still happens.

Here is a discussion about this issue #43

Where would you add this line, please?

  - platform: midea_ac
    host: <IP_ADDRESS>
    id:<PHONE_NUMBER>12345
    scan_interval: 60

@mac-zhou that wouldn't help, just spacing the time between the status changes...
I changed midea-msmart (version 0.1.24) to 0.1.23 as explained in #42 . Now it is working for me.
TNX!

The actual is still UNAVAILABLE, v0.1.23 uses the old state. I'm considering adding an option to be compatible.

@mac-zhou I think it would be necessary. For me, it is working well.
The only problem when the AC is not connected is that it shows 0° (or maybe the last read temp?). Anyway, that is much better than having this unavailable status going on and off all of the time, because I already have other measures to check if the AC is online - I ping all ACs every minute.


fix(analytics_report): change the look of stack report as per ux

Changes:

Introduces Changes in analytical-report-widget.component.html
a. Select boxes for selecting pipelines and builds if present
b. On selecting, show the stack analysis information if any
Uses exposed bayesian functions to get recommendations while hitting its API - analytical-report-widget.component.ts
Changes in styles to support the HTMLs - analytical-report-widget.component.scss

Fixes #814.
Added a few screenshots to highlight the changes visually. (This is because not everyone can see all the flows, you require build associated to see specific analysis)

There were the following issues with your Pull Request

Commit: 159ce78a636b8b6d0c579b815357f2edc8805c33
Your subject line is longer than 50 characters

Guidelines are available at https://github.com/fabric8io/fabric8-ui

This message was auto-generated by https://gitcop.com

There were the following issues with your Pull Request

Commit: 57c61f445d33f1f4d16a90b601045c60e0b99cb8
Your subject line is longer than 50 characters

Guidelines are available at https://github.com/fabric8io/fabric8-ui

This message was auto-generated by https://gitcop.com

There were the following issues with your Pull Request

Commit: 7cf132d10b30dc69a45dacf995137684574b8807
Your subject line is longer than 50 characters

Guidelines are available at https://github.com/fabric8io/fabric8-ui

This message was auto-generated by https://gitcop.com

@arunkumars08 snapshot fabric8-ui is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-816-fabric8-ui.int.rdu2c.fabric8.io

Tested with the staging url and the recent changes are present 👍


Fix Rails 5.2 compatibility

Also:

Renames some native_database_types to match their MySQL names
Better names for Rails column types

test broken
60 runs, 86 assertions, 6 failures, 15 errors, 0 skips

appraisal ar51 rake test
58 runs, 151 assertions, 6 failures, 2 errors, 0 skips
appraisal ar52 rake test
58 runs, 94 assertions, 6 failures, 15 errors, 0 skips

thank @aykamko


Font style setting not saved

On macOS at least, when using a custom font style, the Font style isn't stored in preferences and doesn't persist.
Steps to reproduce:

go to Settings
go to Font Name setting
press the Select... button
select a Font name and a Font style, ex: Menlo Bold 🤷♂
→ only the Font name is stored

fixed in dev #2251


scp not working

Rel #5 - scp doesn't seem to work when connecting to our custom-built dropbear sshd. Likely some extra binary is missing. Needs investigation. (I think this was also broken on devmode sshd, so not really a new bug, but something definitely nice to have fixed)
Quick fix in case anyone stumbles upon this and needs to quickly pull/push a file:
cat local-path | ssh root@tv 'cat > remote-path'
ssh root@tv cat remote-path > local-path

Indeed, run scp verbose (-vvv), this works by invoking scp on the remove (TV) side which obviously we don't have.
I'm preparing a patch, consider this assigned to me.


Unquoted subshell result, incorrect exit code in compute-adam-jars.sh

On a clean repo:
$ bin/compute-adam-jars.sh
You need to build ADAM before running this program
$ echo $?
0

That "You need to build…" should have been preceded by another echo; also: exit code 0?
This is the culprit: unquoted sub-shell call.

Resolved by https://github.com/bigdatagenomics/adam/commit/e7bb9670fff41286f6198219b3ab41a2d1823a13.