I wrote a simple fake processor emulator (dcpu-16). I would like to know if it's possible (and how) to integrate my target into gdb such that I could debug the programs compiled and executed in that emulator.
It seems like it would be related to the gdb "target" or maybe "target exec" commands although I didn't manage to understand how to make it work.
Any help would be appreciated :) Thanks!
Related
I've looked through the internet and searched for solution for debugging xv6 on mac with CLion and didn't find one. as you know it's difficult (or maybe impossible, I didn't succeeded anyway) to make gdb work on macOS.
So, how can I do it? How can I debug xv6 with CLion on macOS?
NOTE that in order to be able to debug xv6-riscv you will need to use riscv64-unknown-elf-gdb instead of gdb
as following:
run make qemu-gdb clean in terminal (in the project's directory of course), pay attention for the port, it may be different for some reason, for me it was 25501.
All I needed to do is the following:
kernel is good for debugging proc.c, if you want to debug other file, (i.e. sh.c) you should put _sh instead.
I'm working on a project where I need to program an NRF51822 using an ST-Link V2 (well, perhaps I don't have to do it this way, but that's what I'm currently doing/own).
I'm pretty sure it's running properly, but I really need a debug console to get some information back from the NRF51 module to make sure things are connected OK.
I'm not going to lie:
I'm really quite new to this, and most of my success thus far has been thanks to quite in-depth tutorials.
I'm using ubuntu and openOCD for programming
I'm not sure what I need to put in my program in order to get debug/console info out (and I'm not even sure what I would do to receive it on my computer).
I would really appreciate some help on:
What to add to my program to log info to the console, and
How to view that debug console on my computer.
Thank you very much!
You need to use such OpenOCD config file to connect with ST-Link
#nRF51822 Target
source [find interface/stlink-v2-1.cfg]
transport select hla_swd
set WORKAREASIZE 0x4000
source [find target/nrf51.cfg]
You need to insert your version stlink-v2-1.cfg or stlink-v2.cfg
Also you need to add this to your makefile to write program
flash: $(OUTPUT_BINARY_DIRECTORY)/$(HEX)
$(OPENOCD) -d2 -f $(TEMPLATEROOT)/openocd.cfg -c 'init_reset halt; program $(OUTPUT_BINARY_DIRECTORY)/$(HEX) verify; reset; exit'
Debug is more complex. You'd better set eclipse with OpenOCD/GDB to make it. For console solution you can follow this lesson
This worked for me. Good luck.
I was wondering if there was any way that I could debug a floppy disk emulation in Linux.
The main thing I want to be able to do is to see the values of registers and custom defined bytes and words as the emulation runs.
Another thing I would like to be able to do is to run the emulation one step at a time, and see what line of code my emulation is currently on.
I am currently just running my floppy disk image under qemu-system-x86_64 and letting it run without any feedback besides the emulation.
If anyone can supply me with something along the lines of command line statements that accomplish this sort of thing, and what programs I could either move to or install alongside to help me out, it would be much appreciated.
I don't have enough idea of qemu because I haven't used it much. But from your requirement perspective, I think you should try bochs emulator. It's quite easy to use and comes with a built-in debugger. Only thing is, you need to compile it from source (if on Linux) making sure the --enable-debug and --enable-disasm switches are enabled (alongwith any other options you might want to enable). (On Windows however, the debugger comes as a pre-built (separate) executable in the installation, but that's sort of irrelevant in your case I guess.)
I'm studying "Compilers" and we work on Flex to program.
I create *.lex files (with any editor), convert them into lex.yy.c via flex, and then compile to a.exe using gcc.
Writing lex code in an editor like Notepad/Codeblocks/... is not only hard because everything is just BLACK, but also there is no debugging system.
The gcc compiler does tell about errors, but what i'm looking for is something i can go line by line with the code (in runtime) and see what's going on with the variables. Like the command F10 in Visual Studio.
Does anybody know a suitable program for this? Thanks alot
Concerning hightlighting, using gedit(The default GUI editor on Ubuntu and some other Linux variants) or even vim will provide that for you, you don't have to use plain notepad.
As for the debugging, yes there's what's called the GNU Debugger (aka GDB) which allows you to do typical debugging jobs after you've compiled your code, you can step line by line and examine certain variable values.
Before doing that, first compile your program with the gcc flag -g to add debug symbols to the complied result, then run gdb yourProgramName, this will run GDB and you'll be able, using certain commands, to do whatever debugging tasks you want.
I once wrote a little guide to help people get started with GDB, it might be useful.
I am wondering which debugging tool I can use for an assembly program and how to use it.
I have written a simple bootloader in assembly. However, it is not quite working properly as I wished, even though I think the logic is correct. So, I am trying to use a debugger so that I can step through the bootloader, checking the register status and etc.
I tried GDB on Ubuntu, compiling my .asm to .elf and .o (Do I need to do it? If yes, what is the next step?) Also, I read that there is an internal debugger in Bochs simulator, but I can't quite find any document how to use it. I also have Visual Studio 2010, windbg, but I don't know how to use it for .asm file debugging.
If you have done this before, it would be an easy answer. Any help would be really appreciated.
Sincerely
If you want to debug bootloader code, you obviously need to run it in the same environment that the code itself is going to run in. As I'm sure you already know, bootloader code is executed in real mode once the BIOS finishes doing the POST. The bootloader is then loaded into memory at 7c00h and a jump to that address is executed.
Obviously, this kind of environment cannot be reliably emulated once you've got your computer running and a "real" operating system already loaded, since by that time your CPU is in protected mode (or long mode, if it's AMD64). Your only option at this point is to use QEMU or Bochs in order to emulate a real PC inside your operating system. I've used Bochs to debug some bootloader code I've written in the past and it worked quite well. Check the manual pages for more detailed instructions.