- This topic has 3 replies, 2 voices, and was last updated 7 months, 2 weeks ago by
.
-
Posts
-
Hello there,
I’m currently evaluating the possibility to use VisualGDB in combination with FreeBSD and llvm/clang as locally run crosscompiler.
Outside of VisualGDB, I’ve managed to get the follwing to run:
- use llvm as a crosscompiler, creating native i386-unknown-freebsd13.3 binaries
- use lldb as a remote debugger (with lldb-server on the target machine running in platform mode)
My reasoning to do so:
llvm is the native compiler used on FreeBSD, and lldb is the complementing native debugger for that, hence no gcc and no gdb.
A native gdbserver installation on FreeBSD seems to be no longer supported.
For understandable reasons, I’d like to use the comfort of Visual Studio together with VisualGDB to to further development.
(With 25+ years experience of working on Windows with various variants of Visual Studio and it’s predessors, it’s not quite easy to change my entire tooling to a *nix based system, and no, I see no need for discussion of that)
For performance reasons, native compilation on the FreeBSD machine is ruled out, as the embedded targets I’m using are rather on the lower end of the performance range (hence also the use of 32 bit code).
I tried to find out what steps are necessary to create a “visualgdb-compatible” toolchain, but failed to find instructions on how to do so.
Where do I find a documentation of the toolchain.xml format and how can I use lldb instead of gdb?
I tried using the lldb variant included in VisualGDB (lldb-mi.exe), just by starting it from the command line, but that doesn’t work. It attaches to the lldb-server in platform mode, is able to copy the target application, to set breakpoints, but fails to launch the remove process with “unknown error”.
Thanks for any clues I’ve failed to find, and please ask for any details I’ve forgotten to give,
Claude
Hi,
The easiest way to get it working would be to download our Raspberry Pi toolchain and use its toolchain.xml file as a template. The format is pretty self-descriptive: you specify a unique ID, name, paths to various tools, and VisualGDB will run them when building the projects. Fields like tool versions are optional and are used to show meaningful summary in the toolchain selector. Fields related to SD card and target version checks can be removed.
Once you have edited toolchain.xml, you can place it into the FreeBSD toolchain directory, click “locate a new toolchain” in the VisualGDB’s toolchain selector, and point it to the new toolchain.xml file. If you edit the file VisualGDB imported the toolchain, you can open and immediately close Tools->VisualGDB->Manage VisualGDB Packages to reload all changes.
As for LLDB, VisualGDB can automatically detect gdb/lldb based on its reply to “info version”, so you can simply put your lldb executable in the toolchain’s bin folder and add the following line to toolchain.xml:
<GDB>lldb.exe</GDB>
This will override the default name of gdb derived from the <Prefix> field.
If the new lldb binary still doesn’t work, you can try checking the Debug->Windows->GDB Session window in the Raw GDB Output mode. It shows all commands executed by VisualGDB, and their replies. If you can point out specific commands that are not being issued as expected (e.g. require some special flags), we should be able to adjust VisualGDB to accordingly as long as you can confirm that running the updated command manually works as expected.
Thanks for your speedy reply.
I’ve now created a toolchain.xml file as follows:
<?xml version="1.0"?> <Toolchain xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <ToolchainName>FreeBSD Clang</ToolchainName> <ToolchainType>Linux</ToolchainType> <PathDetectionKeyStrip>0</PathDetectionKeyStrip> <GNUTargetID>i386-unknown-freebsd13.3</GNUTargetID> <Revision>1</Revision> <ToolchainID>com.sysprogs.toolchains.nongnu.freebsdclang</ToolchainID> <BinaryDirectory>bin</BinaryDirectory> <IsCygwinBased>false</IsCygwinBased> <GCCVersion>17.0.6</GCCVersion> <GDBVersion>13.1</GDBVersion> <BinutilsVersion>2.40</BinutilsVersion> <LIBCVersion></LIBCVersion> <RelativeSysrootPath>..\bsdroot\usr</RelativeSysrootPath> <GDB>lldb.exe</GDB> <GDBExecutable>lldb.exe</GDBExecutable> <GCCExecutable>clang.exe</GCCExecutable> <GXXExecutable>clang++.exe</GXXExecutable> <LDExecutable>lld.exe</LDExecutable> <ARExecutable>llvm-ar.exe</ARExecutable> </Toolchain>
Trying to install this via “locate new toolchain” and creating a new project with the following steps
- Linux project wizard – new project, application, msbuild, language standard c, build system ninja
- build the project locally with a cross-compiler and choosing the just installed toolchain, setting up a ssh connection to my target
gives the following error message: “Failed to launch lldb.exe”
Run "C:\bsdtoolchain\llvm-17.0.6-win32\bin\lldb.exe -v" in directory "" on local computer -------------------------- lldb version 17.0.6 -------------------------- Command exited with code 0 ----- contents of (version regex) ----- GNU gdb( \(GDB\))? ([^ ]+) -----------------------------------
This is the lldb version I’m trying to use. Pressing “ignore” allows me to setup the project after not setting up “gdbserver” on my target machine – this is something for later to worry about, first comes building code.
But when I try to build the project, something else goes quite definitively wrong:
1> System.Exception 1> System.Exception: Missing C:\bsdtoolchain\llvm-17.0.6-win32\bin\arm-linux-gnueabihf-gcc.exe 1> at Sysprogs.Build.Tasks.VisualGDBTask.Execute() 1>C:\Program Files (x86)\Sysprogs\VisualGDB\MSBuild\Targets\gcc.targets(319,5): error : Missing C:\bsdtoolchain\llvm-17.0.6-win32\bin\arm-linux-gnueabihf-gcc.exe
Where does that “arm-linux-gnueabhif-gcc.exe” come from?
What did I do wrong?
Thanks for any clues,
Claude
Hi,
Sorry for the glitch with the forum. We have recently updated the WordPress/bbPress used for the forum, and it turns out that it silently flags posts with more than 1 hyperlink as “pending review”, but doesn’t actually show them anywhere unless you use a special viewing mode.
We have fixed the issue now, pending posts are now properly wired into our internal ticket system.
Regarding the problems with the toolchain, the toolchain testing logic is designed to catch common errors with regular toolchains (e.g. trying the x64 toolchain with an ARM target) and will produce false positives with less commonly used setups. You can simply ignore the errors and should still be able to setup a project. Also, simply ignore the gdbserver configuration as well.
The last error looks like the recently added support for the CXSTM8 toolchain broke MSBuild profile generation for LLVM. We have fixed it in this build: VisualGDB-6.0.101.5158.msi. If it still doesn’t work, you can try creating a project with CMake instead of MSBuild. It relies on CMake to handle the low-level configuration instead of trying to handle everything on VisualGDB side (it can still trigger issues within CMake itself though).
With LLDB, VisualGDB relies on the lldb-mi tool that allows running lldb with the gdb-mi interface. As of 2024, the tool is unmaintained and not included in the normal llvm repository. VisualGDB includes an older version of lldb-mi based on lldb 6.0, however if it doesn’t work with the FreeBSD lldb server, you would need to either build a newer version yourself from sources, or simply use the gdb/gdbserver setup similar to Linux.
- You must be logged in to reply to this topic.