I'm getting a message that prints out of a Linux application (Qt C++) running on an ARM platform:
Unknown HZ value! (108) Assume 100.
This output shows up periodically in different applications with different values in the parenthesis.
It started happening when I switched from a glibc to eglibc based toolchain to build the applications, kernel and filesystem.
Doesn't seem to be causing any ill-effects, at least not of an immediate nature.
Can anyone explain what this means?
This post claims that it means you've been hacked. Here's one with more detailed instructions
For my Linux CentOS 5 machine this ment that the server was hacked. See here how it went.
Related
I'm trying to use GDB to debug Qemu running on m68k architecture. I am attempting to make some changes to Qemu source to add some functionality to m68k support, and I am trying to use GDB to test changes I have currently made. Important to note is that I am using Qemu v5.2.0-rc1, as that is the version of Qemu currently utilized in a larger system that I am concurrently working with. Currently, I am using qemu-system-m68k to run buildroot (uClinux kernel) on that architecture, using the "-s -S" options for gdb. In a separate terminal, I am trying to run GDB on that remote target using (gdb) target remote localhost:1234, but I am getting the following error message:
warning: Architecture rejected target-supplied description
The connection to the uClinux Qemu kernel seems to go okay, but I cannot connect to the remote host.
I have tried finding any possible solutions to this problem, including setting the GDB architecture (currently says i386, not sure if this is right), which does not work. I have no idea how to get GDB running on this m68k Qemu emulated Linux kernel, and any help would be great. Thanks!
The error message means that QEMU's gdb stub sent gdb a description of what the CPU is (mostly a list of registers), and gdb didn't understand it. One common cause of this is trying to debug with a gdb for the wrong architecture.
You need to use a gdb which is aware of the the target architecture. On Ubuntu there is a 'gdb-multiarch' package which has a gdb-multiarch binary that knows about more than just x86. Otherwise you might need to build gdb from source. You can check if your gdb knows about m68k by running it with no arguments and typing the command set arch m68k. If it replies The target architecture is assumed to be m68k then it's OK (and your issue is something more complicated); if it gives you an error (eg Undefined item: "m68k") then you need to use a different gdb.
I want to setup the following environment: I've got a STM32H753I-EVAL2 eval board, connected on a Windows PC. Until now I was developping and debugging locally on this PC with STM32CubeIDE. For several reasons my code source is on a Linux server (Samba mounting) so it takes forever to build a project. Hence I want to develop on the linux server from my Windows machine.
Compiling is working fine (and is way faster) but the issue is about debugging. I know it is possible to debug remotely, the Debug Configuration window from Eclipse (I'm using OpenOcd) allows to connect to a remote GDB server. What I don't know is how to start a GDB server on the Windows machine that will connect to the STM32 board ?
Sorry for the "answer to myself" but I think it might be useful for others (and even to me when I have forgotten in a few weeks ;) ).
Here is how to do.
on host side (on the machine where the eval board is physically plugged in) you have to manually launch the GDB server application that comes with STM32CubeIDE installation. See STMicro application note UM2576 for details. The default command line is:
ST-LINK_gdbserver.exe -d -v -cp "C:\ST\STM32CubeIDE_1.0.0.19w12patch\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.0.0.201903011553\tools\bin"
Now you've done the hardest. On server/remote side you have to setup the Debug Configuration to use OpenOcd with option "Connect to remote GDB server" and simply enter IP address and port number (which is not 3333 by default but 61234, but it can be modified).
This setup is working fine, even if I encoutered some instabilities during debugging once in a while.
I see two (maybe three) options
Use an alternate GDB server (see below)
Run the GDB server from STMCubeIDE in isolation (see OP's answer for Windows, this answer for Linux)
GDB Serial (not really an option right now but I'll share my experience so far)
I have used the second option to succesfully debug my target using arbitary GDBs such as gdb-multiarch command line and in the (non STMCube-ified) Eclipse CDT
Alternative GDB Servers
You could try STLink open source. I did. The problem is, your device might not be supported properly. I built 1.6.1 from Github to enable support for STM32G03x device. While moving to this version enabled it to detect the device, and I can use st-flash to program the device, the debugger is unusable (try and alter a register, it alters the wrong one, try and single step a program, it crashes immediately).
Do try it though .. it's easy and quick to install (or build), so it's worth checking if your device will work correctly with it.
Openocd is another option, but seems not to support SWD connection. I tried a build that allegedly had a patch for this but no luck.
If you can get one of these open source alternatives to work, they have another advantage, you may be able run them on something like a Raspberry PI, which means you don't have to get a PC physically close to your target.
Run the GDB server from STMCubeIDE in isolation
For Windows, see the OP's answer. For Linux, I do this alter the pathnames to suit your installation
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/native/linux_x64/ /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/ST-LINK_gdbserver -p 61234 -l 1 -d -s -cp /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.linux64_1.5.0.202011040924/tools/bin -m 0 -k
How did I get to this? Firstly launched a debugging session from STMCubeIDE, then ran
ps aux | grep gdbserver
Then we can see how Eclipse (STMCube) is launching the gdbserver and work from there.
If you find it complains about a .so file, locate that file from the STMCube installation and ensure the path to the directory containing it is in LD_LIBRARY_PATH (as per my example)
You can also launch the program with --help to show more options.
If add -e (persistent) you can disconnect and reconnect a GDB client without resetting the target (it will reset on initial invocation of the gdb server though, even without -k).
GDB Serial
This is where the target implements the GDB server end of the protocol. The GDB stub usually runs in an exception handler. This would usually be your breakpoint handler but you can also make it the default handler for unhandled exceptions, or, for example, the ctrl-c interrupt.
I have done a lot of Googling about this recently and basically when people ask about it on forums they usually get responses along the lines of "Here be dragons" or "Why don't you use JTAG?"
So the drivers for this, you might like to know, are in the GDB sources git://sourceware.org/git/binutils-gdb.git under gdb/stubs. The documentation is here. There isn't a stub implementation there for arm. Which is sad really, I used to use GDB remote serial regularly where I worked, and some of those targets were indeed ARM. The operating system was ecos.
So could ecos GDB stubs be ported to bare metal? Having giving it a good coat of looking at, I believe yes they could. The stubs are based on the ones from the GDB sources but they are heavily polluted with Ecos and Redboot build macros and copyright (the ogiringals were written by HP and released without copyright). We don't know what bugs the Ecos stubs may contain (I fixed at least one back in the day and I don't recall whether I submitted a patch). We don't know if they really support the latests architectures properly. And, we don't know if, after that, they simply use up too much memory - my STM32 has 8K of SRAM and I already see buffers that have a default size of 2K (not saying that's necessary but you see how work needs to be done here..)
So this third option, I will revisit this one day but for now, for me, it's a nope.
I'm really hoping to get an answer on this. I am using Eclipse to remote debug a C++ program on a (minimal) linux machine. I am aware that the linux machine does not have the locale binary installed. First off, the error received is the following in Eclipse after pressing the debug or run button:
org.eclipse.remote.core.exception.RemoteConnectionException: sh:
locale: not found
After the first run, successive runs do not display the error, only the first run. If I restart the linux machine, the error will come back for the first run again.
What is most obvious is that Eclipse, or the running program is calling locale on the linux machine and it is not available, not installed.
This machine is quite minimal and doesn't even have a package manager - it's an embedded system. So I tried to install "locales", "locale" as well as "locale-all" using multistrap when building the linux image. None worked.
When using debian repositories, multistrap returns
E: Unable to locate packages locales
So I guess my real questions are:
1) What debian package supplies "locale" found in /usr/bin/locale? How
can I install it without adding a lot of of overhead on an ARM system? (assuming no package manager)
2) Where is the source code for locale?
And third,
3) In Eclipse, can I prevent the running program or Eclipse from
calling locale? This is preferred.
After scouring the forums, I found one guy that said he got the same issue and "manually fixed it", however he did not provide the fix.. Hope to get some help!
That reference can be found https://www.eclipse.org/forums/index.php/t/1081283/
Thanks,
I had the same, so I changed the encoding to ISO-8859-1 in the debug settings.
I'm VERY new to CLion so please be gentle :)
I took a project I did for a programming course I'm taking, I managed to build it, but when I tried to run it the CLion just freezes. I tried to run it in debug mode, but no success there either - it waits for a few seconds and then I recieve a message: "command timed out".
I thought the problem might be in my program, so I wrote a simple "Hello World" program - still no success.
few technical specs that might help:
I use CLion 1.2.1 (Newest version).
For my toolchains I use TDM-GCC compiler (downloaded from here: http://tdm-gcc.tdragon.net/download) - I actually do not use the newest version - I use version 4.9.2-3 instead - because I wanted the GDB to be 7.8 so Clion supports it).
My computer runs windows 10 (64 bit), intel core i5-4210U, 8 GB RAM (for what it's worth...)
hope you could help me.
Avast antivirus running … changing its setting as you can find here Stop avast! from attacking my own programs can help...
– nnn
I am using Fedora-16 (64 bit) Operating System.
I have got registered with CloudFoundry and get download "micro-1.2.0.zip" and
"*VMware-Player-4.0.2-591240.x86_64.bundle*". I have successfully installed the "VMware-Player". Then how can install "micro cloud foundry" correctly?
When extract it and run the "micro.vmx" file, then I have got several warring messages and finally got this error message as,
This kernel requires an x86_64 CPU, but only detected an i686 CPU.
Unable to boot - please use a kernel appropriate for your CPU
If some one know how I can over come this problem or what is the correct way to install "MicroCloudFoundry", please help me. Thanks.
You have to check the processor compatibility as well.
Here is the link where you can check the processor compatibility:
http://downloads.vmware.com/d/details/processor_check_5_5_dt/dCpiQGhkYmRAZQ