In gdb, we can use 'pwd' to show the current folder, and use 'cd' to change the current working folder. Does lldb have the same commands?
In lldb, the debugger can create connections to platforms which it will use to upload files, run programs, etc. By default, lldb is connected to the "host" platform, i.e. your local system. You can use platform shell to run commands on the current platform, so to get the cwd, just do:
(lldb) platform shell pwd
You can't use platform shell to change the cwd, since this is a sub-shell, so it's effects don't persist past the execution of the sub-shell. The cwd is a setting of the platform, so you change it with:
(lldb) platform settings -w <NEW_PATH>
Related
I am using Clion and I am unsure how to run a .sh file with my code. It is for an assignment, and I have to run an automatic test to test my code.
This is how it is described to be called: $ ./test_p2.sh 2
I have the shell file in the folder with my code, But I cannot see it in executable or working directory.
Any help is appreciated! Thanks
You can't directly run Linux shell scripts on Windows. You do have a few options, however:
Run your script through Cygwin
Run your script in mintty (this is the shell included with Git for Windows, is called Git Bash in the context menu)
Run your script under WSL (Windows Subsystem for Linux)
Port the script to another language you can run on Windows
For 1 and 2, it'll be on you to make sure any dependencies for the script are available in either Cygwin or mintty.
For 3, after making sure WSL is set up you can run a single command under WSL: wsl script.sh arg1 arg2 argX.
I would recommend option 3 or 4. 3 may offer the best experience in terms of compatibility and ease of set up (without porting the script) as Cygwin and mintty can be a pain to set up dependencies in. Option 4 would be best though as long as you are well-versed in both PowerShell and shell scripts and can transpose the equivalent calls from one to the other.
I installed geany on Fedora.
It compiles and builds my c++ code but it can't run the code.
"Cannot execute build command "xterm -e "/bin/sh /tmp/geany_run_script_BJ09E0.sh"": No such file or directory. Check the Terminal setting in Preferences"
I'm new on Linux and i don't know how to properly set terminal settings.
Depending on your spin, bring different Console Emulators.
For example, Fedora with KDE comes with konsole terminal emulator.
To use konsole with Geany, configure Edit - Preferences - Tools ->
Terminal: konsole -e "/bin/sh %c"
But, if you still want to use the xterm emulator (lighter and faster), you can install it from the repository, leaving Geany with the default configuration.
sudo dnf install xterm
I am trying to run a flask app in my command prompt on Windows 10. Whenever I try to run it, it errors out when trying to import torch. I have created a fresh environment and installed the latest pytorch from this page https://pytorch.org/get-started/locally/ but it still doesn't work in command prompt. Oddly, if I just execute code that says "import torch" in jupyter notebook or VS code, it doesn't error out. It only gives me the error in Command Prompt.
Does anyone know what the issue could be?
Short answer: If possible, use Anaconda Prompt. It's accessible from the Start Menu > Anaconda > Anaconda Prompt.
Long answer: The problem is due to the order of the different Python installations in the PATH variable, as you can see with echo %PATH%. System Python comes first, which can be seen with which python.
The recommendation is to use Anaconda Prompt, since it properly sets up the PATH variable with all required Anaconda paths. More importantly, it avoids interfering with other software in regular command prompt. So, your command prompt won't have any unintended consequences from using Anaconda.
If there is a reason that requires you to use regular command prompt, you can change the order with set PATH=C:\Anaconda\;%PATH% (temporary for this command prompt) or setx PATH=C:\Anaconda\;%PATH% (permanent). There are other libs that may be required to be included as well, which you can check by printing the PATH variable at the Anaconda Prompt.
Another option (Win10): Start Menu > type 'environment' > click 'Edit the system environment variables'. Click Advanced > Environment Variables... Double click Path and change the order between system Python and Anaconda Python.
I am using Ubuntu 16.04 on x86_64 workstation, and I'm cross-compiling a small demo program in C++, and deploying it to an embedded linux target running ARM architecture (environment-setup-cortexa9hf-neon-poky-linux-gnueabi, arm-poky-linux-gnueabi-g++).
I am able to successfully do this which gives me a debug session on commandline:
Target:
rpm -ivh gdbserver-7.10.1-r0.cortexa9hf_neon.rpm
gdbserver :9091 ${APPNAME}
Host:
sudo apt-get install gdb-multiarch
gdb-multiarch $APPNAME
target remote 192.168.0.212:9091
...
I can now use gdb-multiarch on commandline!
However from here... I really want to be able to use one of the many gdb frontend tools to provide a GUI to set breakpoints and step through the code (akin to gdbgui, or using vscode and configuring for a debugger). Are there any gdb frontend tools that specifically support gdb-multiarch?
Any tool I try, I believe no matter what it uses base gdb executable and gives this error because of mismatched architecture:
target remote 192.168.0.212:9091
Remote debugging using 192.168.0.212:9091
warning: Architecture rejected target-supplied description
Remote 'g' packet reply is too long: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000070fdff7e00000000c0fafc76100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
UPDATE 1 --
I can kinda sorta get this to work using ddd tool:
ddd --eval-command="target remote $MY_TARGET_IP:9091" --debugger gdb-multiarch
However! This is ancient and buggy, and I can't set breakpoints in loaded .so's right now with this.
I tried gdbgui with its options to specify debugger, but that's not currently working either. I filed a feature request report here:
https://github.com/cs01/gdbgui/issues/237
I found a way using gdbgui, but it required me to rebuild gdb from source code against my specific remote target architecture. Details of how I got it to work are here:
https://github.com/cs01/gdbgui/issues/237
Important bits in case the above link breaks:
TLDR Solution:
I was trying to rely on a prebuild gdb-multiarch from ubuntu apt repos, which didn't work. When I decided to download gdb and rebuild from source while configuring for arm-linux-gnuabi target arch.
Build method:
downloaded latest gdb source code
unzip it, go into folder, and build it like this:
./configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --target=arm-linux-gnuabi && make -j8 && sudo make install
Important to note that for my particular remote gdb server it's running on ARM so i had to say target=arm-linux-gnuabi in configure. GDB is building for my PC x86 arch, but it knows when debugging to recognize the target as ARM!
Now, arm-linux-gnuabi-gdb is installed by default to /usr/local/bin ... but you can instead provide prefix=<path> to where you want it to install in ./configure script above.
Using this, I was able to build a secondary copy of gdb called arm-linux-gnuabi-gdb which i could feed to gdbgui like this:
gdbgui -g arm-linux-gnuabi-gdb
From there, I can give gdb commands to connect to my remote gdbserver. I'm having to set breakpoints beforehand. My gdb commands are like this to set a few breakpoints:
set breakpoint pending on
break my_object.cpp:<line number for breakpoint>
b example_function_name
target remote <remote arm machine IP>:<gdbserver port>
c
Works great! This is leaps and bounds better than running gdb on commandline on my remote target.
I'm using GCC on Windows 7 (using the TDM's build). I installed MSYS to be able to execute Make and compile using makefiles. However, it is tedious to every time start up the MSYS Bash shell, navigate to the directory of the project and run make.
What I want is to automate this process. I prefer to have a batch file in Windows, or something similar, from which I then invoke the MSYS Bash shell. It should navigate to the directory the batch file resides in and call make.
Is this possible? Can I send commands to MSYS Bash from cmd (like navigation/invoking make)? Or can I let the MSYS Bash run a "Bash script", which sets the commands to be executed much like batch scripts?
PS: This is something similar to Stack Overflow question Executing MSYS from cmd.exe with arguments.
Not an MSYS expert, but does something like this work for you:
rem Call this something like compile-project.bat
c:
cd \src\project
bash -c "make"
You don't have to use bash to execute make, or any of the other MSYS programs. If you put the MSYS bin directory on your path, you can execute them from a Windows command shell. Alternatively, the bash shell has an enormously powerful scripting language built in. But I'm not clear if that's what you are asking about - you should clarify your question with an actual example of what you want to do, spelling out the steps you want automated.
My own setup is to have a Windows Explorer context menu called "Bash here" which opens a bash shell in the directory I select. This is done via the following registry entries:
[HKEY_CLASSES_ROOT\Directory\shell\mybash]
#="Bash Here"
[HKEY_CLASSES_ROOT\Directory\shell\mybash\command]
#="cmd /c c:\\bash.cmd %1"
And the following bash.cmd file in c::
#echo off
title bash
cd %1%
bash
Note that the MSYS bin directory is on my path. And of course, any registry hacking is at your own risk.
Just add executables to your Windows PATH:
C:\msys64\mingw64\bin
C:\msys64\usr\bin
Keep in mind, this adds a lot of executables to your path which might conflict with other applications. The ..\usr\bin directory contains all installed MSYS2 packages. There is a lot of unnecessary stuff. ..mingw64\bin directory has a smaller list.
Source
On my MSYS-1.0.11 with the MSYS developers packages, I can call a bash script (CurrentScript.sh) with a cmd/bat file in the current folder with this command:
R:\MinGW\MSYS-1.0.11\bin\sh "%cd%\CurrentScript.sh"