freedib / lldbmi2

A simple MI interface to LLDB for Eclipse

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Try to run it on arm Mac (M1)

Fabian188 opened this issue · comments

Bildschirmfoto 2022-02-10 um 01 06 39

I just managed to enable lldbmi2 on an Intel MacBook with macOS 12.1 and finally it worked great!

Yesterday I got a new MacBook with M1 Pro und it's blazing fast. My fat C++ applications compiles in 2:30 instead of 11:00!

I have arm-Eclipse, build my code for arm and can debug it manually with lldb (just load and do bt for the stacktrace where it crashes).

I build lldbmi2 again with LLDB_LIBRARY:FILEPATH=/Library/Developer/CommandLineTools/Library/PrivateFrameworks/LLDB.framework

When I debug with eclipse, I get the error message

Error in final launch sequence:

Failed to execute MI command:
-file-exec-and-symbols /Users/fwein/code/master/debug_arm/bin/cfsbin

Failed to execute MI command:
-file-exec-and-symbols /Users/fwein/code/master/debug_arm/bin/cfsbin

lldb /Users/fwein/code/master/debug_arm/bin/cfsbin works.

Is the a way for logging?

A add the log from eclipse:

!STACK 1
org.eclipse.core.runtime.CoreException: Failed to execute MI command:
-file-exec-and-symbols /Users/fwein/code/master/debug_arm/bin/cfsbin

	at org.eclipse.cdt.dsf.concurrent.Query.get(Query.java:112)
	at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugSession(GdbLaunchDelegate.java:252)
	at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugger(GdbLaunchDelegate.java:109)
	at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launch(GdbLaunchDelegate.java:97)
	at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:803)
	at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:716)
	at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1021)
	at org.eclipse.debug.internal.ui.DebugUIPlugin$2.run(DebugUIPlugin.java:1224)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.lang.Exception: 
	at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:1013)
	at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:842)
!SUBENTRY 1 org.eclipse.cdt.dsf.gdb 4 10004 2022-02-10 01:10:50.855
!MESSAGE Failed to execute MI command:
-file-exec-and-symbols /Users/fwein/code/master/debug_arm/bin/cfsbin

!STACK 0
java.lang.Exception: 
	at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:1013)
	at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:842)

Hello Fabian. I'll publish an update to support Command line tools.

For your actual issue, I never tried lldbmi2 from an ARM architecture.

Could you first run "lldbmi2 --version" from command line to ensure it compiled right?

Logging is activated with options "--log --logmask 0x3fff" on the debugger command line after lldbmi2. Logs are stored in "project root"/logs or in current directory if there is no logs directory. I'm not sure if they would be useful in that case. They were more used to trap messages from CDT to the debugger. Actually my setup crashes when I activate logs. I have to check. Probably unpublished changes I made, but your version should be ok.

You could also try to run lldbmi2 manually:

% ./lldbmi2 --interpreter mi2
(gdb) -file-exec-and-symbols /Users/fwein/code/master/debug_arm/bin/cfsbin
(gdb) -exec-run
And tell me the messages

Thanks for the quick response. First the version

./lldbmi2 --version
GNU gdb (GDB) 7.7.1
lldbmi2 version 1.0.163

The command gives an error and I had to kill lldbmi2 to quit it.

./lldbmi2 --interpreter mi2
(gdb)
-file-exec-and-symbols /Users/fwein/code/master/debug_arm/bin/cfsbin
^error
(gdb)
-exec-run
^error,msg="Can not start process. SBTarget is invalid"
(gdb)
^C

^C^C
^C
zsh: terminated  ./lldbmi2 --interpreter mi2

arch shall work

build_arm % file ./lldbmi2 
./lldbmi2: Mach-O 64-bit executable arm64
build_arm % file /Users/fwein/code/master/debug_arm/bin/cfsbin
/Users/fwein/code/master/debug_arm/bin/cfsbin: Mach-O 64-bit executable arm64
build_arm % file /usr/bin/lldb
/usr/bin/lldb: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/lldb (for architecture x86_64):        Mach-O 64-bit executable x86_64
/usr/bin/lldb (for architecture arm64e):        Mach-O 64-bit executable arm64e

I executed the log manually but it does not show more:

082442.021 @@@  ./lldbmi2 --interpreter mi2 --log --logmask 0x3fff 
082442.058 <<=  |(gdb)\n|
082500.365 >>=  |-file-exec-and-symbols /Users/fwein/code/master/debug_arm/bin/cfsbin|
082500.367 <<=  |^error\n(gdb)\n|

Architecture detection of lldbmi2 is weak. I tries to load x86_64 or i386 architecture, even on arm64.
As a rapid fix, you could changes lines 231 and 233 of engine.cpp to replace "i386" and "x86_64" with "arm64".
As soon as I find a way to improve architecture detection, I will update the code on github

Great, that works!
It was also my experience with our C++ codebase that it does not take much to run in on arm64.

Thanks a lot! You made me happy, because it helps me a lot and I'm happy I could help a little improving a great helpful open source tool for further usage. Thanks for your time!

We use for unix like systems uname for architecture detection.
This is macOS with ARM:
uname -p -> arm
uname -m -> arm64
On Intel Linux this is both x86_64

Please note that macOS runs both x86_64 and arm64 binaries. We use optionally a proprietary lib which is only in x86_64 available. I'll then simply compile my stuff with --arch x86_64 (AFAIK there are also environment variables to control the target). So having a cmake switch could be convenient to implement and useful in usage the same time.

I just published v1.1 where lldbmi2 supports flag "--arch x86_64" to add in GDB debugger command line.
Enjoy and tell me if any problem.

Works great! I tested x86_64 and arm64 and both run nicely. Performance debugging in Eclipse with M1 is significantly faster than MacBook Pro 2018.