Running binary build for torizon as executable in docker container instead of default executable

[khaled.hassan]

Hi I compiled an open source project using the cross compiler and before running I changed the executable in docker file and getting below error.
=thread-group-added,id=“i1”
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type “show copying” and “show warranty” for details.
This GDB was configured as “aarch64-linux-gnu”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:
https://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.

For help, type “help”.
Type “apropos word” to search for commands related to “word”.
Warning: Debuggee TargetArchitecture not detected, assuming x86_64.
=cmd-param-changed,param=“pagination”,value=“off”

But I can manually run the docker container and can run manually the executable without any issue.
Need to know how to fix this problem

[ToradexAI]

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

---

The issue you’re encountering seems to be related to the architecture mismatch between your development environment and the target environment. The warning Debuggee TargetArchitecture not detected, assuming x86_64 indicates that GDB is assuming the wrong architecture for your target.

Here are a few steps to troubleshoot and potentially resolve this issue:

1. Ensure Arm Emulation is Enabled:
   Make sure that Arm emulation is properly enabled on your development machine. This is necessary to run Arm binaries on an x86 host. You can enable Arm emulation by running the following command:

   docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
   

2. Check Dockerfile Configuration:
   Verify that your Dockerfile is correctly set up to use the cross-compiled binary. Ensure that the binary is copied to the correct location and that the entry point or command in the Dockerfile points to the correct executable.

3. Verify GDB Configuration:
   Ensure that GDB is correctly configured to recognize the target architecture. You might need to specify the architecture explicitly in your GDB configuration. You can do this by adding the following command in your GDB initialization file (.gdbinit):

   set architecture aarch64
   

4. Use the Correct GDB for Arm:
   Make sure you are using the GDB that is configured for the Arm architecture. The message This GDB was configured as “aarch64-linux-gnu” suggests that you are using the correct GDB, but double-check to ensure there are no mix-ups.

5. Debugging Configuration in VS Code:
   If you are using Visual Studio Code, ensure that your launch configuration (.vscode/launch.json) is correctly set up to use the Arm architecture. Here is an example configuration:

   {
     "version": "0.2.0",
     "configurations": [
       {
         "name": "Torizon C/C++: GDB",
         "type": "cppdbg",
         "request": "launch",
         "program": "/path/to/your/executable",
         "args": [],
         "stopAtEntry": false,
         "cwd": "${workspaceFolder}",
         "environment": [],
         "externalConsole": false,
         "MIMode": "gdb",
         "miDebuggerPath": "/usr/bin/aarch64-linux-gnu-gdb",
         "setupCommands": [
           {
             "description": "Enable pretty-printing for gdb",
             "text": "-enable-pretty-printing",
             "ignoreFailures": true
           },
           {
             "description": "Set target architecture",
             "text": "set architecture aarch64",
             "ignoreFailures": true
           }
         ],
         "preLaunchTask": "build",
         "miDebuggerServerAddress": "localhost:1234",
         "targetArchitecture": "arm64",
         "pipeTransport": {
           "pipeCwd": "",
           "pipeProgram": "docker",
           "pipeArgs": [
             "exec",
             "-i",
             "your_container_name"
           ],
           "debuggerPath": "/usr/bin/aarch64-linux-gnu-gdb"
         },
         "sourceFileMap": {
           "/path/in/container": "${workspaceFolder}"
         }
       }
     ]
   }
   

6. Run the Container with Correct Settings:
   Ensure that when you manually run the Docker container, you are using the same settings as specified in your Dockerfile and VS Code configuration.

By following these steps, you should be able to resolve the architecture mismatch issue and successfully run and debug your cross-compiled binary within the Docker container. If the problem persists, please provide more details about your Dockerfile and VS Code configuration for further assistance.

Please, also check if these links can help you solve your problem:

Can't build Torizon SDP container in Visual Studio

I’m trying to set-up a second Torizon development PC as part of preparing to demo Torizon to my team, but I’m getting an error when attempting to build the Torizon SDK container. The two PCs have the same versions of Windows, Docker, Visual Studio 2017 and the Torizon Visual Studio extension installed. They are both trying to compile the one-line hello world code which is created by default when creating a new Torizon C++ project in Visual Studio. The project has the same name and is in the sam…

Build Boot2Qt to run within docker in torizon

Hello everyone, Currently, we are in the process of developing and producing our own Boot2Qt based image, which you can learn more about here: How to Create Boot to Qt Image | Boot to Qt 6.5.2. In addition to this, we have implemented our custom meta-layer that introduces various drivers and features. Our application utilizes serial ports and CAN Bus functionality. Given that this application serves as the primary GUI for our device, it also facilitates the adjustment of local settings such as…

Torizon .NET Core container not deploying.

[rudhi.tx]

Hello @khaled.hassan

Could you please send your Dockerfile (and docker-compose file if there is one)?
Did you start this project based on a template from our VSCode IDE extension? If yes, which one?
If the files contain some sensitive information, you can also make this post private before you post it here.

[khaled.hassan]

Hi Rudhi,
Please find the attached Dockerfile and docker-compose file.
I started using VSCode IDE extension (I am using Torizon extension)
Dockerfile.sdk (1.2 KB)
Dockerfile.debug (3.2 KB)
Dockerfile (2.8 KB)
docker-compose.yml (420 Bytes)

[rudhi.tx]

Hi @khaled.hassan,

Thanks for your patience. I looked into your Dockerfiles and I don’t see anything obvious that could cause this issue.
I believe you are using our VSCode IDE template for a C++ CMake Console Application. Is that correct?
I could successfully build our template project for C++ CMake Console Application on the VSCode IDE extension and deploy it remotely to a verdin iMX8MP module. You mentioned something about cross-compiling an open source project right? If I were you, I would place the source code for this project in the src directory in the VSCode project folder and compile it from there for the Torizon ARMv8 platform. Could you please give this a try?

[khaled.hassan]

Yes I used C++ CMAKE Application for Torizon.
Right I cross-compiled the opensource project and it compiled successfully.
Issue is while running it gives me error due to GDB can’t handle it.

Best Regards
Md Khaled Ibn Hassan

[rudhi.tx]

Hello @khaled.hassan,

It looks like this has something to do with the name of the executable. VSCode has several files in which the name is hardcoded. If you change the name of the executable, this can mess with the workflow. The easiest way is to revert this name change.