We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
When I try to set a break point in a shared library in DS-5 debugger, I got error as following,
ERROR(CMD440-CMD354-TAD8-NAL79): ! Stepping failed ! Unable to step out of the current function ! Unable to run device 1 ! Failed to enable software breakpoints. Remote GDB returned error code 0x01
There isn't enough information here to diagnose the cause. Could you provide some more information about the circumstances leading up to the error, such as the exact commands that were executed by the debugger (from the Commands view).
When I debug into a shared lib, then I toggle a break point by either run->Toggle Breakpoint or shift+ctrl+B, then step over any instruction from Debug control panel, those messages come up in commands view. I run DS-5 in Fedora 12 x64 i7 CPU.
When you set a breakpoint, the debugger does not actually try to set that breakpoint in your application until you next perform a run or step operation. This means that if the breakpoint fails to be set for some reason, then you might not receive an error until the next run or step, and I think this is happening in your situation.
A reason for the breakpoint failing to set might be because there is a mismatch between the debug information loaded in the debugger and what is actually loaded within your application. A specific example of when this error occurs is if the debugger tries to set the breakpoint at an address where there is no code loaded. Some things that you can check are:
* Have the debug symbols for your application been successfully loaded with the "file" command? You can check the command and any errors in the Commands view.
* Have the debug symbols for your shared library been successfully loaded? The symbols are typically loaded with the "add-symbol-file" command or with the "share" command.
* Are the files containing debug symbols for your application and shared library correctly matching the files that you are running on your board? For example, check that they come from the same build, and don't accidentally contain source code differences.
* Does the address of your breakpoint look sensible and is there code at that address? You can find the address of a breakpoint by entering the command "info break" in the Commands view. Given this address, a quick way to tell if there is code there is to enter that address into the Disassembly view; if an error occurs then this address probably does not contain any code.
When I enter a function in a shared lib. At the beginning, the indicator would jump back, then everything looks normal. I think I use correct lib. The lib is loaded successfully. If I set breakpoint in the lib, but indicator is not in it yet, those messages will come up.
Another problem is I can load the first shared lib successfully, but subsequent libs give errors although I use a script.
add-symbol-file "../libavformat.so.52.55.0" 0x0 ERROR(CMD16-COR97): ! Failed to load image "libavformat.so.52.55.0" ! Range 0x0000D2F4..0x0000D307 overlaps with range 0x0000D22C..0x0000D8B3 currently in map add-symbol-file "../libavutil.so.50.12.0" 0x0 ERROR(CMD16-COR97): ! Failed to load image "libavutil.so.50.12.0" ! Range 0x000075FC..0x0000886F overlaps with range 0x00008148..0x00008167 currently in map
set start-at main start .. source /v "/home/tang/Project/workspace/script"
Ah, this might be the cause of the breakpoint problems too. The "add-symbol-file" command currently requires an offset, which is the address where the shared library is located in memory. It is unlikely that your shared libraries are located at address 0x0, but determining the correct offset is not very easy. If you specify 0x0 for all of these, then not only is the location wrong but you will get overlap errors when doing this with multiple libraries.
We are intending to improve the "add-symbol-file" command in a future release to not require an offset when loading a shared library and to work this out automatically.
What you can do in the meantime is to use the "set so-lib-search-path" option to point at the directory on your computer containing the shared libraries, and once the libraries have been loaded by your application you can then issue the "sharedlibrary" command to load the debug symbols. Since it looks like you are already using a script file, I would recommend that you put these commands in your script so that you can easily re-run them each time you debug your application.
A similar problem and solution are described in the following knowledgebase article:
http://www.keil.com/support/docs/3489.htm