I am trying to debug an aarch64 Linux kernel loaded in QEMU from x86 host. When 'lx-symbols' command executed for loading the symbols from gdb, it has shown
Undefined command: "lx-symbols"
The I have tried executing 'add-auto-load-safe-path' command as shown below
gdb-multiarch /mykernelbuild/linux/arch/arm64/boot/Image
gdb) target remote localhost:9000
Remote debugging using localhost:9000
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
add-auto-load-safe-path /mykernelbuild/linux/scripts/gdb
Still 'lx-symbols' is returning error. I have tried adding this to '~/.gdbint' and restarting 'gdb-multiarch' as well. I have tried adding the filename also to the path
add-auto-load-safe-path /mykernelbuild/linux/scripts/gdb/vmlinux-gdb.py
still no success, any hint is greatly appreciated...
gdb-multiarch /mykernelbuild/linux/arch/arm64/boot/Image
You are debugging Image, and not vmlinux. So GDB will attempt to auto-load Image-gdb.py (which is nowhere to be found).
I have no idea what boot/Image is, but you probably want to be debugging boot/vmlinux instead.
Update:
add-auto-load-safe-path /mykernelbuild/linux/scripts/gdb
Now GDB is complaining about the /mykernelbuild/linux/scripts/gdb not being in the auto-load-safe-path (which it wouldn't be since you haven't added it yet).
You want something like:
gdb-multiarch -ex 'add-auto-load-safe-path /mykernelbuild/linux/scripts/gdb' \
/mykernel/linux/vmlinux
Related
I am currently trying to get going with developing additional functionality for the MonetDB DBMS. I have been reading through the code and tried to debug the code using VSCODE which actually works fine. However, I encountered difficulties when trying to run tests that are already present in the repo using Mtest.py.
To come to the current point, I have forked the latest version of MonetDB (11.40.0) and proceeded with installing it on my ubuntu 20.04 by following the shipped debian documentation:
CONFIGURE_OPTIONS="-DCMAKE_BUILD_TYPE=Debug -DASSERT=ON -DSTRICT=ON"
cd build
cmake $CONFIGURE_OPTIONS
cmake --build .
cmake --build . --target install
The above statements install the applications in the default location. I have also tried to alter the installation direction using -DCMAKE_INSTALL_PREFIX flag. However, this lead to the same results and problems running the tests.
For running specific test cases I have tried the following two thing:
cmake: cmake --build . --target mtest
Mtest.py: Mtest.py sql/test/Tests/
Both attempts lead to the same console output:
Perl available, but MonetDB driver or DBI module not available
abort: there is no Mercurial repository here (.hg not found)
cannot write timeout message mserver5 --debug=10 --set gdk_nr_threads=0 --set mapi_listenaddr=all --set mapi_port=30201 --set mapi_usock=/var/tmp/mtest-16710/.s.monetdb.30201 --forcemito --dbpath=/usr/local/var/MonetDB/mTests
Mtest.py: ERROR: No output from mserver5 when checking for Bits, Modules & Threads!?
It states that the started mserver5 instance is not responding properly somehow. I have currently no clue how to tackle this issue. Can anyone tell me if I might missed out on something?
I have checked the build flags and the corresponding TESTING flag is set on default. Is there anything I messed up with mserver5 or I might have to configure separately?
Looking forward to hearing from you,
Martin
I finally found the reason for my issue with running MonetDB's tests. Thanks to #Joeri van Ruth for making playing around with mserver5 application.
The problem was that I commented in the definition of _SQL_COMPILE in the file sql_execute.sql in order to view the generated MAL code and other debug output generated along compilation. The problem with this is that it calls mnstr_printf and is printing to stdout. This debug output to somehow interferes the required communication and mserver5 cannot respond correctly.
I encountered the problem that I wanted to have a debug, then I wanted to build a debug version of tensorflow, using the following command:
bazel build --compilation_mode=dbg -s //tensorflow/tools/pip_package:build_pip_package
but it will trigger the longtime link in protobuf for almost oneday, and still not finished.
and my intension is to build some other package which is used by tensorflow with debug mode, could I configure the bazel build file to get some debug package separately?
To understand the issue better, try running the neverending action manually:
start the debug build, wait for it to get stuck in the protobuf linking action
interrupt the build (Ctrl+C)
run the build again with the -s flag, so Bazel shows the command line it executes (you could've ran step 1. with the -s flag, but then there's a lot more output and it's harder to find the right information)
interrupt the build again
cd into the directory shown in the by command and set environment variables
try running the command that failed (you may need to change the output paths because they are sometimes not user-writable) and see if it still never finishes
What you just did is running the same command Bazel was running and getting stuck on. If the command is stuck in this manual mode too, then the error might be with the linker (I doubt this is the case though). But if it succeeds, then the problem is with Bazel.
I am trying to build my software using cygwin-x86(32 bit version) on Windows-7.
Cygwin-x64(64 bit) works perfectly fine on the same machine. I want to build 32-bit executable.
Whenever I try cygwin-x86, I get the following errors:
[main] make 7780 child_info_fork::abort:
C:\cygwin\bin\cygiconv-2.dll: Loaded to different address:
parent(0x440000) != child(0x5F0000) make: fork: Resource temporarily
unavailable
I have checked this thread Cygwin Error
I have already tried everything mentioned in there, but I still continue to face the same issue.
Whenever i try /usr/bin/rebaseall -v or cd /usr/bin && ./rebaseall -v as mentioned in the step 7 of the accepted answer in the above mentioned thread, I get this error:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygvtv_stubs-0.dll: skipped
because wrong machine type.
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll: skipped because wrong
machine type. Segmentation fault (core dumped)
I get this wrong machine type error for a lot of other .dll's as well.
As mentioned earlier I have cygwin-64 installed on my machine & working as expected. But while running rebaseall it is somehow looking for x86-64-pc-cygwin instead of 32 bit version.
The thread is obsolete.
run /usr/bin/rebase-trigger, close all cygwin processes and run again setup-x86.exe. Also without installing anything will execute a rebase for you.
You can also specify the option full.
Additional note:
The most likely cause of fork problems on 32 bit system are too many programs and libraries installed.
for example:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll
belongs to cygwin64-zlib a cross library for building cygwin64 programs from cygwin32. Do you really need it ? If not, as I suspect, remove all cywgin64 packages .
The problem can also be triggered by an anti-virus program. (I saw it happening with Avast.) You can test if this is the cause by disabling it.
Could also be caused by this update
https://support.microsoft.com/en-us/help/4561616/windows-10-update-kb4561616
You can also kill each of the latest process of ash, dash or bash that was forked, setup.exe will simply skip this script and continue with the rest.
I had to kill about 10-20 of them, mostly in latex postinstall scripts.
For me, the solution was to remove the .new file extention of the libs from c:\cygwin64\bin\
I had the same problem using git. various dlls depending on the git command used where included in the error message stating that it was loaded to "different adress".
In fact a corporate antivirus or a loaded program had probably prevent un update during the rebase phase while installing a new program (git-svn in my case)
some required libraries where not installed but cleverly left in the target with the .new file extention.
I just had to remove the .new extention (and rename the original lib to .old) to solve the problem.
In my case the list of lib involved was:
cygcrypto-1.1.dll
cyggcc_s-seh-1.dll
cygintl-8.dll
cygwin1.dll
this is an error i got when i run radius server in debugging mode radiusd -X.
i checked a lot and i unable to get the logic,why it is really happend.
root#amsys-ThinkPad-R61:/home/amsys/freeradius-server-2.2.5# radiusd -X
radiusd: error while loading shared libraries: libfreeradius-radius-020205.so: cannot open shared object file: No such file or directory
when i prefectly installed radius server,why i got this problem??
if anyone would aware about this, kindly give prompt response to me ,that how to get out this error.you are really appreciable.
You probably moved the libraries after installation, and your linker path didn't include the location where you moved them to. Use ldd -v <path to radiusd> to show where the linker assumed the libraries were going to be located.
This is sort of a followup to this thread--unfortunately I didn't make any progress at the time so I thought I would start over. I am consistently getting this in the debugging log (QtCreator 2.3.1, Qt 4.7.3, gdb 7.2):
A syntax error in expression, near 0'.\n"
295^error,msg="A syntax error in expression, near0'."
&"Python scripting is not supported in this copy of GDB.\n"
296^error,msg="Python scripting is not supported in this copy of GDB."
&"Python scripting is not supported in this copy of GDB.\n"
297^error,msg="Python scripting is not supported in this copy of GDB."
&"Python scripting is not supported in this copy of GDB.\n"
298^error,msg="Python scripting is not supported in this copy of GDB."
&"Undefined command: \"bbsetup\". Try \"help\".\n"
299^error,msg="Undefined command: \"bbsetup\". Try \"help\"."
dThe debugging helper library was not found at .
&"source /home/matt/QtSDK-4.7.3/pythongdb/gdb\n"
&"/home/matt/QtSDK-4.7.3/pythongdb/gdb:1: Error in sourced command file:\n"
&"Undefined command: \"\". Try \"help\".\n"
300^error,msg="/home/matt/QtSDK-4.7.3/pythongdb/gdb:1: Error in sourced command file:\nUndefined command: \"\". Try \"help\"."
&"Undefined command: \"bbsetup\". Try \"help\".\n"
301^error,msg="Undefined command: \"bbsetup\". Try \"help\"."
dThe debugging helper library was not found at .
302^done
<303set substitute-path /var/tmp/qt-src /usr/include
The specific problem is that without the debugging helper, I'm unable to see the contents of QStrings and many other data structures during the debugging process, which makes it much more time-consuming. The error messages above are symptomatic, the problem arises when gdb can't find the debugging helper.
Anyway, looking at the discussion referenced in the answer in the above thread, I hunted around for different versions of gdb on my system but each one of them produced the same error (with the path changed appropriately of course), including version 7.3.1 when I downloaded it. I've also located libDebuggingHelper.so, but sticking it in different places hasn't helped either. Lastly looking at ./configure --help for gdb, I didn't see any options for enabling/disabling python in the build. Anybody know how I can get this to work?
This site claims you need to configure GDB using
./configure --with-python
It's pretty clear from the error message that the GDB you built does not have python support compiled in.
In gdb/config.log look for messages like checking whether to use python and see why GDB decided to not use Python on your system.
Perhaps you need to install Python development packages?
Once you've configured GDB to use Python, an easy way to check whether Python support is properly compiled in is:
(gdb) python print "hello"
If that prints anything other than hello, you are still not where you want to be.
I solved the problem with
sudo apt-get install gdb-multiarch
Thanks to #Employed-Russian for allowing me to check if GDB indeed has python support.
I did have to use the syntax
(gdb) python print("Hello")
To get a proper response from python within GDB.