Today I got the error message below when I wanted to use cscope with vim.
Error detected while processing /home/yl/.vim/plugin/cscope_maps.vim:
line 42:
E568: duplicate cscope database not added
Press ENTER or type command to continue
Then finally find the working solution here
https://blogs.oracle.com/natarajan/entry/avoiding_duplicate_cscope_database_error
To fix this issue, you will need to simply edit the file "~/.vim/plugin/cscopemenu.vim" (or whatever your plugin is named) and edit the line :
set cscopeverbose
to
set nocscopeverbose
You can also do the same by doing this by adding this line "set nocscopeverbose " to your ~/.vimrc file as well.
Wednesday, February 26, 2014
Thursday, July 25, 2013
Talking in GDB Protocol - How to support Software Breakpoint
Recently I have been working on a OS project and my job is to build debugging support. More specifically, I am writing a GDB stub for an OS. I will not talk about the OS itself here but only some details of my work writing this GDB stub.
Here we are debugging a "remote" target with GDB. Unlike debugging local programs, GDB talks the remote target (the OS to be debugged) to via network/serial port connection, in a language called GDB Protocol. In this protocol, GDB send requests to the remote target to do various things, like read/write register/memory, insert/remove breakpoint/watchpoint, single step, resume execution (after single step or breakpoint), etc.
There are many articles talking about how to write a GDB stub. And you can easily find sample code, for example, remtoe.c on Linux. I am not going to repeat these things. Today I want to talk specifically about how to support software breakpoint.
If you want to play with GDB protocol, simply type in GDB prompt "set debug remote 1" so the packets sent/received will be shown on screen.
Let's assume that we want to break at a certain address. The basic idea of software breakpoint is to replace the instruction at this address with a breakpoint instruction, i.e. "INT 3" for x86 or "BRKT" for ARM. When the control flow executes to this address, the breakpoint instruction will bring you to breakpoint handler (actually an exception handler). Now GDB can interact with stub to debug the target, i.e. examine memory, insert watchpoint, etc. When the user types "continue" or "step" in GDB, the control flow on target should resume from the breakpoint.
But how to resume? Of course we should put the original instruction at breakpoint back and jump to that address. Then the breakpoint is gone and we will not break at here again. However we usually expect breakpoint to persist. After playing with GDB for a while, here is what GDB does with breakpoint:
1. GDB remembers all the breakpoints.
2. When target halts (e.g. hits a breakpoint), GDB sends 'z' commands ("remove breakpoint") to tell stub to remove all active software breakpoints. This might be so that when you examine instructions, you will see the normal ones, rather than inserted breakpoint instructions. Note that when execution is later resumed, the normal instruction at this breakpoint will be executed, rather than the breakpoint instruction (otherwise you will jump to breakpoint handler again when you try to resume).
3. When user requests to insert a software breakpoint, GDB does not immediately send 'Z' command ("insert breakpoint").
4. When user requests to continue, GDB tells stub to single step to the next instruction. Then GDB sends 'Z' commands to insert newly requested breakpoints and temporarily removed breakpoints. This way, the breakpoint we recently hit is recovered and thus software breakpoints will persist.
5. I think GDB does not care how the stub implements single step. It simply tell the stub to single step. If hardware single step is not supported, you will need to implement software single step. Hope the above description may help someone working on GDB stub like me. Good luck with yours!
Here we are debugging a "remote" target with GDB. Unlike debugging local programs, GDB talks the remote target (the OS to be debugged) to via network/serial port connection, in a language called GDB Protocol. In this protocol, GDB send requests to the remote target to do various things, like read/write register/memory, insert/remove breakpoint/watchpoint, single step, resume execution (after single step or breakpoint), etc.
There are many articles talking about how to write a GDB stub. And you can easily find sample code, for example, remtoe.c on Linux. I am not going to repeat these things. Today I want to talk specifically about how to support software breakpoint.
If you want to play with GDB protocol, simply type in GDB prompt "set debug remote 1" so the packets sent/received will be shown on screen.
Let's assume that we want to break at a certain address. The basic idea of software breakpoint is to replace the instruction at this address with a breakpoint instruction, i.e. "INT 3" for x86 or "BRKT" for ARM. When the control flow executes to this address, the breakpoint instruction will bring you to breakpoint handler (actually an exception handler). Now GDB can interact with stub to debug the target, i.e. examine memory, insert watchpoint, etc. When the user types "continue" or "step" in GDB, the control flow on target should resume from the breakpoint.
But how to resume? Of course we should put the original instruction at breakpoint back and jump to that address. Then the breakpoint is gone and we will not break at here again. However we usually expect breakpoint to persist. After playing with GDB for a while, here is what GDB does with breakpoint:
1. GDB remembers all the breakpoints.
2. When target halts (e.g. hits a breakpoint), GDB sends 'z' commands ("remove breakpoint") to tell stub to remove all active software breakpoints. This might be so that when you examine instructions, you will see the normal ones, rather than inserted breakpoint instructions. Note that when execution is later resumed, the normal instruction at this breakpoint will be executed, rather than the breakpoint instruction (otherwise you will jump to breakpoint handler again when you try to resume).
3. When user requests to insert a software breakpoint, GDB does not immediately send 'Z' command ("insert breakpoint").
4. When user requests to continue, GDB tells stub to single step to the next instruction. Then GDB sends 'Z' commands to insert newly requested breakpoints and temporarily removed breakpoints. This way, the breakpoint we recently hit is recovered and thus software breakpoints will persist.
5. I think GDB does not care how the stub implements single step. It simply tell the stub to single step. If hardware single step is not supported, you will need to implement software single step. Hope the above description may help someone working on GDB stub like me. Good luck with yours!
Labels:
breakpoint,
debug,
GDB,
GDB Protocol,
GDB stub,
software breakpoint
Wednesday, August 8, 2012
Thursday, February 2, 2012
Monday, November 21, 2011
2011.11.20
1.解决实验室打印机不能在fedora下双面打印的问题。
重新安装打印机,在选择驱动程序的时候,选择CUPS+xxx(忘记名字)。
2.安装tex-live package。
将sty文件拷贝到/usr/share/texmf/tex/latex/pkg_name/
运行texhash,使得tex-live能够识别新的package
重新安装打印机,在选择驱动程序的时候,选择CUPS+xxx(忘记名字)。
2.安装tex-live package。
将sty文件拷贝到/usr/share/texmf/tex/latex/pkg_name/
运行texhash,使得tex-live能够识别新的package
Thursday, November 17, 2011
2011.11.17
Fedora 15 installation issues:
1.Stall on bootup.
Fedora tries to bring up wireless connection and blocks there.
Solution: disable wireless on bootup
How-To:
1.Diagnose.
Edit grub booting options, delete "rhgb" and "quiet" to disable graphics in booting. So we can see what is happening during booting.
The result is that fedora hangs when trying to bring up wireless connection. (It should do this in background but it didn't.)
2.Enter single mode to fix.
Edit grub booting options, add "single" to enter single mode.
Go to /etc/sysconfig/network-scripts and find any wireless config file.
Edit those config files, modify to "ONBOOT=no".
2.Go Issue
Can't find certain package in Go, and after compilation binary won't run.
Solution:
Make sure $GOOS and $GOARCH are correct.
ethos/etn and ethos/types should be built and installed separately.
1.Stall on bootup.
Fedora tries to bring up wireless connection and blocks there.
Solution: disable wireless on bootup
How-To:
1.Diagnose.
Edit grub booting options, delete "rhgb" and "quiet" to disable graphics in booting. So we can see what is happening during booting.
The result is that fedora hangs when trying to bring up wireless connection. (It should do this in background but it didn't.)
2.Enter single mode to fix.
Edit grub booting options, add "single" to enter single mode.
Go to /etc/sysconfig/network-scripts and find any wireless config file.
Edit those config files, modify to "ONBOOT=no".
2.Go Issue
Can't find certain package in Go, and after compilation binary won't run.
Solution:
Make sure $GOOS and $GOARCH are correct.
ethos/etn and ethos/types should be built and installed separately.
Monday, May 23, 2011
Browser automatically requesting favicon.ico
I wrote a http server using Google's GO Language. However the problem I confronted is not related to the language itself.
I think in certain situations, browsers automatically request favicon.ico as a little icon in the address bar. But my http server fails to properly handle this situation and causes itself to stuck.
It is not the same if I use nc to send request. Simply use "nc IP PORT" to connect, and then:
GET /test.html HTTP/1.0
and hit Enter two times
nc just sends and receives raw data, thus no automatic icon request. So my http server works in such situation with bug in it.
I think in certain situations, browsers automatically request favicon.ico as a little icon in the address bar. But my http server fails to properly handle this situation and causes itself to stuck.
It is not the same if I use nc to send request. Simply use "nc IP PORT" to connect, and then:
GET /test.html HTTP/1.0
and hit Enter two times
nc just sends and receives raw data, thus no automatic icon request. So my http server works in such situation with bug in it.
Subscribe to:
Posts (Atom)