Problem solved. For the benefit of the group and the searchable list archives, I'll describe here what was going on.
My build on Windows, using makegdal80.sln, was generating a gdal15.dll with symbols and gdal15.pdb file. For whatever reason, these files did not contain sufficient information for me to step in to the code in a debug session. After poking around for some time, I found that the OPTFLAGS in nmake.opt were set to the optimized build. I'm not sure why I was seeing the debug symbols loading, but changing OPTFLAGS to generate a gdal.pdb (along with the gdal15.pdb) gave me the debug information I needed. (In 1.6.0, the OPTFLAGS is set for debug when DEBUG is defined, which seems to make more sense.) On Fri, Dec 19, 2008 at 11:22 AM, Joel Odom <[email protected]> wrote: > More notes on the issue below. > > > ---------- Forwarded message ---------- > From: Joel Odom <[email protected]> > Date: Fri, Dec 19, 2008 at 11:21 AM > Subject: Re: [gdal-dev] Debugging on Windows Using Visual Studio > To: Frank Warmerdam <[email protected]> > > > I'm building from makegdal80.sln. I'm also starting my debug sessions > from this same solution. I'm getting symbols in gdal15.dll and the > .pdb file, but I still can't set a break point anywhere. It's like > the debug symbols don't map correctly to the source code. > > I'm wondering if there is some flag in the makefile options that is > not being set, so the program debug information is incomplete? I am > able to set a break point in my dll that calls gdal, but not anywhere > in the gdal methods. Again, this is all in VS 2005. I'll post an > answer here if I figure out the problem before I give up, but if > anyone has any ideas, I'd appreciate it. > > > > On Fri, Dec 19, 2008 at 11:10 AM, Frank Warmerdam <[email protected]> wrote: >> Joel Odom wrote: >>> >>> Bruce. I'm trying to debug an app that uses GDAL from unmanaged C++ >>> on Visual Studio 2005. I've tried for an hour or two to step into >>> gdal, running debug sessions both from the project file from which I >>> build gdal and from the app that calls into GDAL, but even when I run >>> from the gdal solution itself, it still doesn't let me step through >>> source code, even though the modules window says gdal15.dll is loaded >>> with symbols from the same location as my .pdb file. >> >> Joel, >> >> I have generally not had problems with this. Did you build GDAL using >> the nmake files or the solution? I've had good luck debugging the >> utilities and into GDAL itself with visual studio. I normally run things >> from the commandline and pop into visual studio when things crash (even >> triggering crashes at select points). >> >> This is usually with visual studio 2003. >> >> Best regards, >> -- >> ---------------------------------------+-------------------------------------- >> I set the clouds in motion - turn up | Frank Warmerdam, >> [email protected] >> light and sound - activate the windows | http://pobox.com/~warmerdam >> and watch the world go round - Rush | Geospatial Programmer for Rent >> >> > > > > -- > http://giscoder.blogspot.com/ > > > > -- > http://giscoder.blogspot.com/ > -- http://giscoder.blogspot.com/ _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
