I'm using Eclipse CDT with Zylin embedded debug (native) and arm-elf-gdb 6.6 on OS X 10.5.8.
I've got an OCD debugger connecting to a board with an ARM processor.
Eclipse is able to stop at the first breakpoint and gather variables from memory, but any subsequent breakpoints or single-steps fail. I can set breakpoints ok when using commandline gdb, but setting breakpoints at the exact same location gives me these errors in Eclipse:
Warning:
Cannot insert breakpoint 2.
Error accessing memory address 0x3f6: Unknown error: -1.
And my OCD connection dies with "Error: unexpected error -308"
I'm using the same OCD script in both cases.
The only differences I see are (1) Eclipse uses Zylin and the mi protocol to talk to gdb, and (2) my gdb script is invoked differently in this way:
When running from gdb, I use a script file that ends with these two lines:
load filename.out
symbol-file filename.out
In Eclipse, I copy the contents of this script file into "Debug Configurations | Commands" (I've tried both the "'Initialize' Commands" and "'Run' Commands" boxes. I replace the last two lines with load, and specify filename.out in the "Debug Configurations | Main | C/C++ Application" box.
I'd appreciate any suggestions about how to get Zylin+Eclipse to behave.
Thanks.
I'm using the same solution on a LPC2103.
Go to Eclipse, in Zylin Debug Configurations > Embedded Debug (Native):
Main tab: C/C++ Application = you_elf_file.elf
Debugger tab: GDB debugger = arm-elf-gdb; GDB command set = Standard; Protocol = mi2
Commands:
'Initialize' commands:
target remote localhost:3333
monitor arm7_9 dcc_downloads enable
monitor arm7_9 fast_memory_access enable
monitor arm7_9 dbgrq enable
monitor reset halt
monitor wait_halt
monitor sleep 500
load
'Run' commands:
continue
I'm using parallel port Wiggler and OpenOCD [Open On-Chip Debugger 0.4.0] with the cfgs that came with the installation:
openocd -f interface/parport.cfg -f target/lpc2103.cfg
It works most of the time for me.
Related
I'm using the Mypy extension in VSCode, and it's giving me the error mypy failed with error: Daemon has died . See Output panel for details.
When I open the Output panel, it doesn't give me much more info than just telling my that it tried to run dmymy.EXE but that it had died.
How do I get the Mypy extension working again?
I've tried searching for this error on Google to no avail, and I've also tried rebooting VSCode, which gives me the same error every time.
Open up a Command Prompt (on Windows) or Terminal (non-Windows). Copy/paste the location of the dmypy.EXE script that it tried to run (from the output panel). Put start after the script. This will start the daemon.
The command looked like this for me:
C:\Users\MyUsername\AppData\Local\Programs\Python\Python38\Scripts\dmypy.EXE start
Now, reboot VS Code (I'm not sure if this is even needed), and the mypy extension should work again.
In gdb I can type watch &variable, then continue and gdb will break whenever something writes to that address.
I am using vscode to debug and want to do the same thing (This is different from the watch window, which will only show variable values after a breakpoint has been hit). Is it possible?
I can manually add a breakpoint by clicking the '+' and enter &variable but it never becomes active and says the module has yet to be loaded. I've tried manually entering -exec watch &variable in the debugger console window, but after continuing execution with the play button it hangs (vscode thinks the program is running again but it's not).
There are some github issues for this but they're closed without reason:
https://github.com/microsoft/vscode/issues/55931
https://github.com/microsoft/vscode/issues/47117
https://github.com/microsoft/vscode-debugadapter-node/issues/38
I had luck watching on an address. For example, if my target variable was at address 0xb79b90, I would execute -exec watch *0xb79b90 in the gdb terminal. Then I'd double check it was added as a hardware watchpoint with -exec info watch.
After continuing execution, the debugger would halt with an exception once the watchpoint is hit. vscode would display the line after the value was changed. I could then continue from there if necessary.
For several reasons I must test my program with multiple computer restart.
So I need at the computer startup, eclipse open and the tested program runs in eclipse (in debug mode if possible).
Can you give me a command line or another way to do that. I just need when I open eclipse or when I use the given command line, the program automatically start
Thank you
For Linux OS (not sure on Win, Mac), Eclipse (or other apps) can be automated with xdotool utility. Assuming your app has run at least once in debug mode within Eclipse so it exists an entry on Debug history, a Bash script could do the following actions
-Edit the script below to set the correct position value for the app.
-Launch Eclipse.
-Wait some time until is fully up.
-Execute the following command sequence:
#!/bin/bash
position=6
#find Eclipse app window IDs, keep the last one
e_wid=$(xdotool search --class Eclipse | gawk 'END{print $0}')
# Create basic command string
cmd="xdotool windowactivate --sync $e_wid"
# Send key strokes with some delay in between
# Open Run menu
$cmd key Alt+r
sleep 1
# select Debug option
$cmd key h
sleep 0.5
# pick the sixth option in that menu
$cmd key $position
It's recommended to mark the app as a favorite so it gets a constant order in the menu.
To see another example, check this mluis7 gist at Github.
Running Firebird 2.5 as a service on a local 64-bit Windows 10 machine.
isql, qli and a bunch of the other tools run just fine.
However when I try an launch gfix, gbak and gstat the window barely opens before disappearing. It does this so quickly nothing is visible.
Any recommendations for dealing with this?
My actual goal at the moment is to change a firebird database from read-only to read-write. Which you can do using gfix http://www.firebirdsql.org/manual/gfix-dbmode.html
If there is some other method to change to read-write I'd happily use it.
The tools gfix, gbak and gstat are command line utilities. They expect certain command line options, and they print their output to the console. If you start them by double-clicking them in explorer, or executing them from the Run prompt, a console is opened, output is written (the usage information as you haven't specified the necessary command line options), and then it exits, closing the console immediately.
This means that if you want to run them and see the output, you need to execute them from the command prompt (cmd), or from a batch-file that has pause at the end.
The fact qli and isql work by opening them from explorer (or run) is because they are interactive tools, waiting for your input.
I have a 32-bit desktop, where my copy of emacs is running.
I'd like to be able to debug a program running on a very stripped down qemu 64 bit virtual machine.
The virtual machine has an ssh port 24054, which gives me passwordless root access, and it does have gdb installed.
And it has the directory which my desktop calls ~/myco/chip_test mounted as /9p
So if I make a hello.c file in ~/myco/chip_test,
then go to the 64 bit machine in which the VM will run, and compile it with:
$ gcc -o hello -g hello.c
then start the virtual machine, and on my 32-bit desktop run
$ ssh -p 24054 root#anvil 'cd /9p && gdb ./hello'
Then gdb runs perfectly in command line mode in a window on my desktop.
So now of course I want it to run under emacs, because the command line gdb is a bit hard to read, and I'd like to see my cursor stepping through the file, and have windows with watch variables and so on.
So I try M-x gdb
Run gdb(like this): ssh -p 24054 root#anvil cd /9p && gdb --annotate=3 ./hello
And I get a debugger window up in emacs and everything looks right, in fact I can even set and remove breakpoints by clicking in the fringe of the ~/myco/chip_test/hello.c file in my local emacs, which is the same file as what gdb sees as /9p/hello.c, but the moving cursor doesn't appear or move around, so the whole thing is fairly useless.
So I think that emacs/Gud doesn't quite realise that ~/myco/chip_test/hello.c is the file that the debugger thinks is /9p/hello.c, although obviously something interesting is happening since I can set breakpoints, and so I wonder if there is a way to get one or another programs in the loop to translate the filenames so that everything just works.
Any ideas, or am I just going about this all wrong?
You'll get much better results if you either
mount /home/<user>/myco/chip_test on /home/<user>/myco/chip_test in the
VM (so the source paths match exactly), or
run gdbserver in the VM, and connect local GDB to it.