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.
Related
I'm using SSDC Compiler for PIC micro-controllers, and it supposed to have a supported debugger called (SDCDB). Although, in compiler settings it shows Invalid Debugger in debugger option. So, how can I specify the SDCDB to be my default debugger. And, is there any problems using GDB with SDCC compiler?
This only answers part 1 of your question. I don't know what happens when you use gdb with SDCC.
You will need to be an admin user for this
Look for options_sdcc.xml in %programfiles%\CodeBlocks\share\CodeBlocks\compilers
Open the file in an editor. Look for DBGconfig on the windows platform. Set the value to sdcdb.exe
I am developing embedded C for a TI MSP430 microcontroller, and have spent the last couple days migrating from TI's IDE and proprietary toolchain to a more unix-y workflow of Sublime Text + make + gcc. I'm now trying to set up debugging with WinGDB (Visual Studio with gdb backend) and I've got it mostly working. There's just this one issue with breakpoints which I suspect comes down to a backslash / forwardslash issue, but I don't know how to fix.
I can start debugging without problems, I can step through, view disassembly, etc. But when I try to set a breakpoint in the source file using F9, it shows up as disabled with the hovertext:
The breakpoint will not currently be hit. No source file named d:Documentsccs workspacesmsp430 scratch\013cxmain.c.
Location: main.c, line 13 ('main(void)')
However, I can set and clear working breakpoints with gdb commands in the WinGDB debugger shell, but no little red circles appear next to the source.
The path to main.c is D:\Documents\ccs workspaces\msp430 scratch\vcx\main.c and I discovered that the escape sequence \v corresponds to a vertical tab, or octal \013 in ascii. So I'm guessing the backslashes are screwing something up somewhere (thanks windows).
Any ideas where to look to fix this?
Your error shown is usually generated when your code is optimised by the compiler - such as a = 2; and never used again. But the main problem(s) could be related to your cross toolchain - on this link the cross toolchain implemented in WinGDB is CodeSourcery G++ Lite toolchain for ARM, while your micro, MSP430 is not an ARM device. (there is an MSP432, which is ARM device).
Maybe you can look at this: www. Energia.nu, something similar to Arduino, works with several versions of MSP430.
You are correct that it is a backslash problem, the debug records generated for your files which tell the debugger which file & line resulted in which group of op codes.
You can try modifying your build process to use forward slashes everywhere, since your tool chain is gcc based it should find files named
D:/Documents/ccs workspaces/msp430 scratch/vcx/main.c
but you are also likely to have problems because of spaces in your path, restructure your project so that all spaces are replaced by underscores i.e. D:\Documents\ccs workspaces\msp430 scratch\vcx\main.c gets moved to D:\Documents\ccs_workspaces\msp430_scratch\vcx\main.c etc, spaces in paths can cause all sorts of issues. While it is possible to escape spaces in paths it is better to just avoid them.
I would also suggest taking a look at Code::Blocks - while not as pretty as VS it does a much better job of providing an IDE and debug environment for cross platform and embedded development. It is free, cross platform and open source itself. It interfaces with GDB very well and you can customise the build tool chain that it uses for your project(s). It even comes with presets for GNU GCC for MSP340, as well as many others, so should be very helpful.
Is it possible to get a complete disassembly (which can act as input to an assembler) of an executable?
When I use otool -tV a.out I get to see only the text section. Other sections like data aren't visible.
When I use gdb, the disassemble command requires a start and an end address. However I do not know how to find out the start and the end address of a binary (say a.out).
I'm trying to disassemble an executable, tinker with the assembly code and then reassemble it.
Is that possible?
It'd also help if one can find out the names of all the sections in a binary.
Try using this command, i remember using it sometime back:
otool -tvV a.out
On Mac, you can install (possibly by homebrew) binutils that includes gobjdump. You can disassemble any binary program once installed. It's open and free.
You can use the Hopper Disassembler
quote:
Hopper is a reverse engineering tool for the Mac, that lets you disassemble, decompile and debug your 32/64bits Intel Mac executables.
It costs $59, but you can download a demo to check if it gets the job done first.
EDIT
It seems you can achieve this with otool as well, according to the manual.
.B -d
Display the contents of the (_^_DATA,_^_data) section.
Also have a look at this short blog post (archive link, original is gone) that describes the mentioned use of otool, and how you can use objdump as mentioned by #Sjlver.
On linux, you can try to use objdump -D myprog
Note that this will work only if the program does not contain irregular control flow. Especially malware is often obfuscated, e.g. by inserting spurious bytes that are then jumped over.
If you're targeting this kind of programs, I've heard that one of the best products to use is IDA pro.
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.
When debugging a program in Code::blocks, how do you specify command line arguments to be sent to the program being debugged. I can't find where to set this for the life of me and google searches bring up settings for debugging the compiler itself, rather than programs written in the compiler. It would be a strange thing to leave out.
Thanks,
Tim.
Ah, looking with a visual studio head on. It's not in the project settings dialog but off the project menu:
Project->Set Programs Arguments