QEMU & Syborg Debugging
From Symbian Developer Community
The Symbian Virtual Platform (SVP) allows stop-mode debugging of Symbian ROM images running on a PC in the QEMU emulator.
Contents |
Preconditions
You require a Symbian image which boots on the Symbian Virtual Platform as described here
You'll need Carbide.c++ v2.4 or later, which you get as part of the ADT or PDT.
Instructions for older versions of GDB and Carbide are available in an older version of this page.
Download and install ARM-NONE-SYMBIANELF tools
Download and install "Symbian ADT Sourcery G++ Lite 4.4-172 for ARM SymbianOS" from CodeSourcery. The latest release is on this page: http://www.codesourcery.com/sgpp/lite/arm/portal/release1258
Install elf4rom
ELF4ROM creates symbol and debug information for your ROM image.
- Download elf4rom.zip and extract the tool.
- For comprehensive documentation on the tool see elf4rom
- Source code is in \sf\adaptation\qemu\tools\elf4rom.
Setup PATH
You'll need your PATH properly setup. A real-world example:
C:\Program Files\CodeSourcery\Sourcery G++ Lite\bin;c:\apps\actperl\bin\;C:\Perl\site\bin;C:\Perl\bin;C:\apps\Python26\Scripts;C:\apps\Python26\;c:\apps\rvct22_686\bin;c:\apps\atool;c:\apps\ccm65\bin;C:\WINNT\i386;C:\WINNT\System32\Wbem;C:\WINNT;C:\WINNT\system32;\epoc32\tools;\epoc32\gcc\bin;\epoc32\gcc_mingw\bin;c:\apps\actpython\.;c:\apps\perforce\;c:\program files\novell\zenworks\;c:\winnt\i386;c:\winnt\system32\wbem;c:\program files\intel\wireless\bin;c:\program files\quicktime\qtsystem\;c:\program files\intel\wifi\bin\;c:\apps\7zip;c:\apps\bc;c:\apps\jedit;c:\apps\tortoisesvn\bin;c:\program files\nokia\fasttrace;c:\apps\cltools;c:\apps\gracecli\bin;c:\apps\wget;c:\apps\ant_1.7.1\bin;c:\apps\code collaborator client;C:\Program Files\Java\jdk1.6.0_17\bin;c:\WINNT\system32;C:\Program Files\TortoiseHg;C:\Program Files\Nokia\FastTrace;C:\Program Files\MySQL\MySQL Server 5.1\bin;C:\APPS\unzip;C:\APPS\symdec;C:\Symbian\Tools\PDT_1.6\raptor\bin;C:\Symbian\Tools\PDT_1.6\ConE;%APPDATA%\Python\Scripts;C:\APPS\HookLogger\;c:\apps\elftools;C:\Program Files\Code Collaborator Client;c:\build_c\cygwin\bin;
- Note G++ Lite is at the beginning
- The mingw is actually from epoc32\gcc_mingw
- If you are a Cygwin user, put it at the end of your Path as shown here. This is to avoid conflicts with DOS-based tooling.
- TODO This could be pruned down to the bare essentials
Debug Setup
Create an ELF file from your Symbian ROM image
Example:
cd \sf\os\kernelhwsrv\kernel\eka\rombuild elf4rom.exe -i SYBORGARMV5D.IMG -l SYBORGARMV5D.log -o SYBORGARMV5D.elf -p 0x0 -d _SYBORG_EKERN.EXE _SYBORG_KASYBORG.DLL _SYBORG_ESERIAL.PDD _SYBORG_EKEYB.DLL
- This example assumes that the location of elf4rom.exe as been added to path environment variable
- SYBORGARMV5D.log is used here, if you didn't explicitly rename it when you built the ROM it'll be called ROMBUILD.log
- The resulting ELF file in the is SYBORGARMV5D.elf
Read more about elf4rom usage in \sf\adaptation\qemu\docs\wiki\ELF4ROM.doc
Create a Makefile project in Carbide.c++
- Create a new directory under your Carbide workspace directory and copy your elf file to the directory
- Start Carbide.c++ (if not already running)
- Create a new C++ makefile project. File -> New -> Project
- Tick the Show All Wizards checkbox and select C++ -> C++ Project
- Click Next and agree to turn on hidden UI feature
- Type the directory in which your elf file is located to the Project name field
- Un-tick the Show project types and toolchains only if they are supported on the platform box
- Select Makefile Project -> Empty Project and in the toolchains box select MinGW GCC
- Click Next and then Advanced Settings
- Expand C/C++ Build and click Settings. In the Binary parser window un-tick PE Windows Parser and tick GNU Elf Parser
- Select the GNU Elf Parser option to make the commands addr2line and c++filt visible. Change addr2line to arm-none-symbianelf-addr2line and c++filt to arm-none-symbianelf-c++filt. (NOTE: If you dont have the directory of the CodeSourcery tools defined in your path you must give the full path for these executables.)
- Click OK
You should now be able to to explore the contents of your ELF file in the Project Explorer view of your eclipse environment. To test the environment navigate to syborg_keyboard.cpp and add a break point to DKeyboardPs2Soc::Isr() method. (Note: Depending on configuration, you may get to navigate the elf file by symbol rather than filename - need to investigate what causes this - in this case, you'll have to select the mangled symbol name, right click and select add breakpoint).
Create a debug configuration
- In the eclipse UI click Run -> Debug Configurations.
- Right-click GDB Hardware Debugging and click New
- In the resulting menu choose Main tab
- Give a good name to your configuration
- Select the project you created in the Project box
- Type your ELF file name in the C/C++ Application box
- Select Disable Auto Build
- Select the Debugger tab
- Type arm-none-symbianelf-gdb in the GDB Command box
- Un-tick Use remote target
- Select the Startup tab and type tar rem localhost:1234 in the Run Commands box
- Click Close
Start your debug session
- Start simulation
- Start a command prompt and change to the directory for the Carbide workspace project you just created - the one your elf file is located in
- Start your QEMU syborg Symbian simulation.Example: <path to your build environment>\symbian-qemu-0.9.1\bin\arm-none-symbian-elf-qemu-system.exe -M <path to your build environment>epoc32\rom\syborg\syborg.dtb -kernel SYBORGARMV5D.elf -S -s
- At this point the QEMU Symbian simulation window should appear (with QEMU [Stopped] label on it)
- Connect debugger to simulation
- In your eclipse UI click Run -> Debug Configurations
- Now you should have your Debug configuration visible in the "Debug Configurations" dialog - if not, select it from the list
- Press Debug in the bottom right of the dialog
- If your eclipse perspective is not switched automatically to Debug click Window -> Open Perspective -> Debug
- You don't need to worry about possible error "No symbol "new" in current context." visible in the Console window
- In the "Console" window enter "c" (or you can click the green arrow in the IDE to continue debugging - this will give an error the first time but work properly after that)
- Now you should have your Symbian simulation booted up
- Enter a keypress to your Symbian window and you should hit to a previously added breakpoint in DKeyboardPs2Soc::Isr method
Debug Notes
- Be carefull with your path environment variable setup. For example it seemed to cause problems if eclipse was able to found previous gdb installation (like http://downloads.sourceforge.net/mingw/gdb-6.6.tar.bz2).
- Read more about debugging from your Symbian syborg environment \sf\os\QEMU\docs\wiki\Stop-mode Debugging.doc
- If you re-create the elf file, for example when adding extra components to debug, go to Carbide’s project view for the elf file and hit refresh (F5).
Using GDB commands directly
You can use GDB commands directly if Carbide.c++ doesn't provide what you need.
- Select the Console tab, then click on the "picture of a display" icon and select the console which has "arm-none-symbianelf-gdb" in the name
- Click in that window and type gdb commands, e.g. "info registers" to get the current content of the ARM registers, "x/64w $sp" to dump the contents of the current stack in hex, or "help" for info on GDB commands (hint: "apropos xxx" is a good way to track down the command you need, if you aren't familiar with GDB).
There is a tool epoc32/rom/printsym.pl which can attempt to identify and decode ROM addresses, which may help to fill out the calling context for functions if you don't already have the necessary DWARF information in the image. Run the script, specifying the ROM symbol file as the argument, then paste fragments containing addresses into the window and see the attempted translations: for example, this fragment of the stack (from "x/128w $sp").
M:\epoc32\rom>perl \epoc32\rom\tools\printsym.pl syborg_001.minigui.symbol
ROM Symbols from syborg_001.minigui.symbol
Please enter data to be decoded
0x40e3a0: 0x00000018 0x30000008 0x00000010 0x65537a54
= 00000018 ....
= 30000008 ...0
= 00000010 ....
= 65537a54 TzSe
0x40e3b0: 0x72657672 0x80000001 0x00000002 0x10000008
= 72657672 rver
= 80000001 ....
= 00000002 ....
= 10000008 ....
0x40e3c0: 0x807c44f0 0x00000001 0x807c44ec 0x00000004
= 807c44f0 .D|.
= 00000001 ....
= 807c44ec .D|.
= 00000004 ....
0x40e3d0: 0x807c44bc 0x807bfe39 0x3fffa364 0xffffffff
= 807c44bc .D|.
= 807bfe39 9.{. RTz::Panic(RTz::TPanic) timezone.o(.text) + 0x14
= 3fffa364 d..?
= ffffffff ....
0x40e3e0: 0x00000004 0x807c0147 0x00000000 0x00000000
= 00000004 ....
= 807c0147 G.|. RTz::Connect() timezone.o(.text) + 0x72
= 00000000 ....
= 00000000 ....
0x40e3f0: 0x00000000 0x3fffa290 0x00010100 0x3fffa010
= 00000000 ....
= 3fffa290 ...?
= 00010100 ....
= 3fffa010 ...?
0x40e400: 0x00000000 0x3fffa290 0x00000354 0x807d71cd
= 00000000 ....
= 3fffa290 ...?
= 00000354 T...
= 807d71cd .q}.
0x40e410: 0x00000000 0x00800130 0x00800130 0x008000e8
= 00000000 ....
= 00800130 0...
= 00800130 0...
= 008000e8 ....
0x40e420: 0x008000e8 0x00700000 0x3fffa364 0x3fffa098
= 008000e8 ....
= 00700000 ..p.
= 3fffa364 d..?
= 3fffa098 ...?
0x40e430: 0x3fffa030 0x807e8e1c 0x807e8e20 0x807d53d8
= 3fffa030 0..?
= 807e8e1c ..~.
= 807e8e20 .~.
= 807d53d8 .S}. _E32Dll uc_dll_.o(.emb_text) + 0x0
0x40e440: 0x00000000 0x807d9bb9 0x807e8e1c 0x807d541c
= 00000000 ....
= 807d9bb9 ..}. __sti___11_localif_cpp localif.o(.text) + 0x8
= 807e8e1c ..~.
= 807d541c .T}.
0x40e450: 0x00000002 0x007000ec 0x00000002 0x807e5d7c
= 00000002 ....
= 007000ec ..p.
= 00000002 ....
= 807e5d7c |]~. _E32Dll_Body uc_dll.o(.text) + 0x14
0x40e460: 0x007000ec 0x800fb217 0x00000008 0x8061c6e8
= 007000ec ..p.
= 800fb217 .... RLibrary::InitL() up_lib.o(.text) + 0x36
= 00000008 ....
= 8061c6e8 ..a. _E32Dll uc_dll_.o(.emb_text) + 0x0
0x40e470: 0x80697c18 0x807d53d8 0x807ea338 0x80821088
= 80697c18 .|i. _E32Dll uc_dll_.o(.emb_text) + 0x0
= 807d53d8 .S}. _E32Dll uc_dll_.o(.emb_text) + 0x0
= 807ea338 8.~. _E32Dll uc_dll_.o(.emb_text) + 0x0
= 80821088 .... _E32Dll uc_dll_.o(.emb_text) + 0x0
0x40e480: 0x807fb008 0x8069b158 0x806a30b8 0x00000100
= 807fb008 ..⌂. _E32Dll uc_dll_.o(.emb_text) + 0x0
= 8069b158 X.i. _E32Dll uc_dll_.o(.emb_text) + 0x0
= 806a30b8 .0j. _E32Dll uc_dll_.o(.emb_text) + 0x0
= 00000100 ....
0x40e490: 0x302e3020 0x53203030 0x63726165 0x20646568
= 302e3020 0.0
= 53203030 00 S
= 63726165 earc
= 20646568 hed
0x40e4a0: 0x20726f66 0x696e692e 0x74657320 0x676e6974
= 20726f66 for
= 696e692e .ini
= 74657320 set
= 676e6974 ting
0x40e4b0: 0x44207b20 0x75616665 0x202c746c 0x54414422
= 44207b20 { D
= 75616665 efau
= 202c746c lt,
= 54414422 "DAT
0x40e4c0: 0x7d202241 0x00740065 0x00690074 0x0067006e
= 7d202241 A" }
= 00740065 e.t.
= 00690074 t.i.
= 0067006e n.g.
Mapping a directory on the host OS to the QEMU S: drive
A very useful feature of QEMU is the ability to map a directory on the host OS to the S: drive.
To do this create a directory called svphostfs in the root of the drive from which QEMU is run. For example, if QEMU is run from the C: drive create C:\svphostfs.
Files can be copied to the S: drive in the emulated Symbian OS environment and they will appear here. This makes retrieval of logs very straightforward.
Additionally you can copy files to the mapped directory (i.e. 'svphostfs') and then copy them to the appropriate location in the Symbian OS instance. You can even create a directory 'svphostfs\sys\bin' and copy binaries there to make them usable in the Symbian OS. This feature reduces much of the need for building ROM images.
Comments
Contents |
Davidcrookes said…
Markw said…
Hi David,
I haven't had a more complex rom than a text shell to test this with yet. I did notice that you can set breakpoints in source without expanding the ELF in the project explorer. Not sure if that helps.
When I have time to play with a full UI ROM I'll see if I can reproduce - that may not be for a couple of weeks I'm afraid, so please report back if you fix it in the mean time.
--Markw 19:14, 5 January 2010 (UTC)
Davidcrookes said…
Hi Mark,
I've not solved the problem but I suspect I've identified something like it. I grabbed lots of source from the eclipse-cdt project and although I've not proved it, I found in the "old" source the following FAQ, dev.eclipse.org:/cvsroot/tools/org.eclipse.cdt/old/cdt-home/user/faq.html#troubleshooting_20
“Whenever I build the project, the eclipse hangs (gets "stuck"). I need to kill a process named: "c++ filt" to restart it. Why? There was a bug in the old version of c++filt that did not flush its output when it finishes (this same problem happens with addr2line). CDT is waiting for the answer from c++filt. You need get a new version of c++filt to fix the problem.”
I don't actually see the source in my project view, and was relying on the elf file to set initial breakpoints.
--Davidcrookes 11:55, 6 January 2010 (UTC)
Markw said…
Sounds like you've indentified the component with the problem. Regarding source in the project view, IIRC, I found I could just open source files from the correct location and set breakpoints in them, even though they didn't appear within the project in the IDE. That might only be the case if c++filt is working of course...
--Markw 11:11, 7 January 2010 (UTC)
Davidcrookes said…
Some more notes. 1. I don’t know about anyone else, but internally here, we’ve noticed that the section above:
“Create a Makefile project in Carbide.c++…11. Select the GNU Elf Parser option to…"...
doesn’t quite work for us. One can set the new tools <gnuarmpath>\arm-elf\addr2line but this setting seems to revert for us (carbide 2.1). I cheated here by copying my gnuarmpath’s exes to the default names of addr2line.exe and c++filt.exe in the same path.
2. Regarding my problem of expanding the ELF, if you take the advice of the old Eclipse-CDT FAQ, and kill c++filt, then you will see Carbide become responsive again, and interestingly some parts of the ELF file symbols are displayed and can have a breakpoint toggled on them. This breakpoint would break when execution occurs, but I have been finding that stepping was not predictable and didn’t seem to allow step-in effectively.
3. I tried to open source files directly , and Carbide would allow me to toggle breakpoints pre-execution anyhow, but it transpires that this never works. When I tried this, executions would fail, carbide reporting that the ELF and GDB had exited with code 35584. This looks like to be arm-elf-gdb failing, in my view. The reason I say this is because I enabled gdb verbosity (Run->Debug configs -> Debugger tab -> Verbose console mode) and the exit seems to occur when the breakpoint in the source file is set using gdb’s commands. I discovered arm-elf-gdb.exe.stackdump files were being left around. I started to suspect that this may be to do with the fact that the gnuarm tools recommended use cygwin and so my system’s cygwin1.dll is being used here. I am upgraded to cygwin 1.7.1. The gnuarm pages show links to cygwin 1.5.x source.
While investigating these issues I was examining whether the binutils were upto date and noticed that there is a gnuarm derivative project, YAGARTO, http://yagarto.de/ This version avoids cygwin and presumably uses mingw or some such. Installing the instance yagarto-bu-2.20_gcc-4.4.2-c-c++_nl-1.18.0_gdb-7.0.1_20091223.exe (look at http://www.yagarto.de/index.html#download) and getting rid of gnuarm from paths, and reconfiguring everything to use the binutils in the yagarto installation, along with removing cygwin from the path seemed to give much better results now. I still hit the “c++filt hang” problem, but on killing that, the ELF file symbols that are shown are now de-mangled. Also, open a source file, inserting a breakpoint, is working when I launch an execution. I’ve been stepping into browserng.exe functions ok, as long as I have the symbol data in the ELF.
So I think a step forward.
--Davidcrookes 17:01, 7 January 2010 (UTC)
Paulb said…
For Run Mode debugging with Carbide, see http://developer.symbian.org/wiki/index.php/Carbide.c%2B%2B_Run_mode_Debugging_of_Qemu_using_TRK
--Paulb 21:35, 14 January 2010 (UTC)
William roberts said
I'm working through this page in April 2010, and things seem to have moved on. The current PDT (1.6) contains Carbide.c++ 2.4.0, which has "Help | Install new software..." and is primed with "Carbide.c++ Update Site - http://tools.ext.nokia.com/updates/carbide23". It has "Eclipse GDB Hardware Debugging Version: 5.1.0.v201001151122_90" pre-installed, so I've skipped all of that installing step. The gcc 4.4.1 compiler is available from the PDT download page (see the Freedom Fighters walkthrough for details) but doesn't contain gdb. Elf4rom source has appeared in the sf/adaptation/qemu package, though the binary is most easily obtained from the embedded zip file.
Using the latest drop from CodeSourcery (Symbian ADT Sourcery G++ Lite 4.4-172) the executables are called "arm-none-symbianelf-*", rather than "arm-elf-*", but the rest of the instructions seem to be basically OK. The hardware debug support does seem to be installed, and I've successfully attached to QEMU. To see the source code I needed to use the "executables" tab in the debug perspective, and then I was able to open sutils.cpp and put a breakpoint on K:Fault.
I'm on my way, and now I need to compile the things which seem to be dying.
William roberts 16:13, 15 April 2010 (UTC)
Davidcrookes said…
I was using stop-mode with both pre-release CodeSourcery tools, Yagarto and another ancient instance of GDB (can't recall name) a few weeks back. I was having issues that were dependant upon which component I tried to debug. i.e GDB would crash. No GDB worked ok. Please let me know if you see component dependant failures too.
--Davidcrookes 22:54, 15 April 2010 (BST)
William roberts said…
I've spent a few more hours doing this, and it's a pretty shoddy experience: what follows is all through Carbide.
1. Attempting to view memory always fails 2. Stepping over functions sometimes ends up inside them, e.g. inside small inline functions. If in doubt, do extra "Step into" to get past that point, but DO NOT do "Step Out" as this will behave like "resume". 3. Stack traces fail at the first unrecognised symbol (I suppose that's inevitable as there's no frame pointer)
As a simple improvement, I'd like elf4rom to sketch out the rest of the ROM structure - at the very least it could magic up e.g. "centralrepository.exe .text" from the info in the rombuild log to make the debugger provide some clues about the unknown stuff - better still it could include the symbols from the map files so that you'd know which function was involved.
--William roberts 17:15, 16 April 2010 (BST)
Faimemon said…
I keep getting errors like: Creation Time Description Resource Path Location Type 1279822654367 Error launching external scanner info generator (g++ -E -P -v -dD C:/Symbian/workspace/.metadata/.plugins/org.eclipse.cdt.make.core/specs.cpp) fourthstopmode Unknown C/C++ Problem
I changed the path for to have code sourcery early on, and change g++ command to be arm-none-symbianelf-g++.exe
I could not find the GDB version that William pointed out on the update site either.
So I think I have an initial setup problem.
I have cygwin, PDT 1.6, mingw, etc. installed.
Does anyone else get the external scanner error when the project has been created (whilst containing a something.elf file)
--Faimemon 19:22, 22 July 2010 (BST)
Faimemon said…
My issue is now fixed. I had to hack down my PATH somewhat (compared mine to another engineer who had it working). I documented a "working" configuration for PATH in this web page. Hopefully it helps others.
--Faimemon 18:31, 5 August 2010 (BST)
Sign in to comment…
I have a found a problem perhaps worth noting. I got this going on a customer environment, as described above although I had problems with paths, where originally my path contained \epoc32\gcc\bin. This was picked up by Carbide and when carbide used addr2line or c++filt, these programs would use the cygwin1.dll found in \epoc32\gcc\bin. This would cause a silent failure in Carbide for me, but noticeable when running these tools myself on the command line.
When I got this going, it was using a udeb version of eshell.exe in the config file used with elf4rom. However, I am more interested in debugging browserng.exe in my rom. When I try the same process with a udeb version of this executable, an unsolved problem occurs. I can open the project but in the project explorer view, when I attempt to expand/open the ELF file binary (syborg_001.OBEYFILE.elf for me), Carbide becomes non-responsive and hangs. I’ve not waited beyond 30 mins or so but Windows task manager shows Carbide/addr2line/c++filt as running but using no CPU. Addr2line has memory usage of ~0.75GB. The ELF file in this use case is ~275MB in size, versus ~100MB for the eshell experiment. I suspect that the binary parsers are barfing somehow here for too big a use case.
I’ve not worked out how I can diagnose what happens here yet. Suggestions more than welcome.
--Davidcrookes 12:30, 5 January 2010 (UTC)