Up to: Mika Raento's Symbian Programming pages
There are no debug symbols provided for the Symbian OS code in either the Nokia Series 60 version 1 or version 2 SDKs. This, although not catastrophic, makes it harder to debug your own applications if a crash occurs inside the platform code. The code and instructions on this page will allow you to generate 'exports'-level debug symbols for the libraries for use with Visual Studio 6 and .Net.
The dlls included in the SDK don't even have by-name exports, only by-ordinal. However, the mapping between ordinals and the names exists in the LIB files. The task is then to parse this mapping, read the export address and generate DBG files. The problem is complicated by the fact that the exported addresses are for the jump table and not the actual functions and that generating DBG files is pretty hard.
Using the jump table just means that you have to actually look in the dll and decode the target of the jump. This is done in the symbols.pl perl script. I wouldn't know how to generate the DBG files from scratch but luckily Lucian Wichik has written some code that does it (originally for converting Borland's MAP files to the DBG format). I've used that as a base to create dbggen which reads a textual description of the symbols created by the perl script and writes out a DBG file.
Unfortunately Visual Studio .NET doesn't grok
the old DBG files anymore, so these can be only used with VC6.0.
Visual Studio .NET can use .DBG files, but it requires the dll to
list the file in the debug directory (see
this post at microsoft.public.vc.debugger).
Istvan Hajnal (Pisti) has written a utility called DbgMaker that
makes the necessary modifications. Download DbgMaker
(note that older versions don't work quite right with the Symbian dlls).
for %i in (*dll) do ( perl symbols.pl %i dbggen %i )
for %i in (*dll) do ( DbgMaker -mb %i )
After that you should see something like Loaded symbols for 'd:\symbian\7.0s\Series60_v20\Epoc32\release\wins\udeb\euser.dll' in the Visual Studio output window when starting the emulator. If you don't, something's gone wrong. I probably won't have any good ideas about what, but I'd like to hear if you have had to some modifications to make it work. Now you can set breakpoints in system functions like EUSER::RHeap::Alloc and see the stacktrace in system components.
The caveats given e.g. in Geoff Gray's article about export symbols are valid. If you don't know what this means, go read up on them.
All this is based on some not necessarily universally valid assumptions like what the dll segment offsets are, what the jump table looks like and so on. YMMV.
All the symbols are prefixed with the dll name, like ESOCK::RConnection::RConnection. In setting the breakpoint, you have to first figure out where the class and method come from. I use the highly advanced tool 'grep' for this.
Mika Raento, mikie(at)iki.fi