Re: unable to set breakpoint
- From: "Dave Calkins" <david.calkins@xxxxxxxxxxxxxxx>
- Date: Fri, 1 Feb 2008 08:42:25 -0500
Sorry, I am a bit confused by your following statement:
"By updating the C/C++ option, I'm not able to set a breakpoint and do
source-level debugging on the library regardless of where its located on
my
machine."
I am not sure if the word "not" is a typo or not since you said you had
found the problem.
sorry, talk about an inconvenient typo :) It was supposed to say, "I'm now
able to set a breakpoint ...", i.e. its working now and I don't need to have
the binaries in their original built locations.
Regarding your original workaround, I suspect this is an internal
algorithm
of VS debugger. Actually, the simplest way to tell the VS debugger where
to
probe the source code files is setting the "Source Paths":
Right click Solution / Properties / Source Paths
This should be a simple solution without maintaining a source server.
Yes, the source paths do seem to work well when needed. Once I understood
what was going on, I renamed the source dir to "hide" it and sure enough,
when trying to step in the code VS prompted me for the source file. I added
the altered directory to the source path and it then found it on its own.
Granted, with this approach its purely filename matching which is where the
source server you mentioned earlier would come in. I haven't yet
investigated as to whether or not it would work with our revision control
system (the info I've read about it refers to VSS and I think CVS).
Regarding the debug information generation in compiler and linker, the
great article below should be informative:
"generating debug information with visual c++"
http://www.debuginfo.com/articles/gendebuginfo.html
The PDB file format is undocumented, so I do not know of a tool to examine
it yet.(If anyone can share one, I'd like to hear) I think we have to use
dbghelp.dll API to check the source file information in it. Another simple
way is using the "!lmi" command in windbg, see the "Load Report: private
symbols & lines, source indexed" line below:
0:000> !lmi ntdll
Loaded Module Info: [ntdll]
Module: ntdll
Base Address: 7c800000
Image Name: ntdll.dll
Machine Type: 332 (I386)
Time Stamp: 45d70ad8 Sat Feb 17 22:02:00 2007
Size: c0000
CheckSum: bd6f9
Characteristics: 210e perf
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 22, 86a6c, 85e6c RSDS - GUID:
{93E72E10-9DC8-4F16-AA54-797E4DA8C168}
Age: 2, Pdb: ntdll.pdb
CLSID 4, 86a68, 85e68 [Data not mapped]
Image Type: FILE - Image read successfully from debugger.
C:\WINDOWS\system32\ntdll.dll
Symbol Type: PDB - Symbols loaded successfully from symbol server.
c:\LocalSymbols\ntdll.pdb\93E72E109DC84F16AA54797E4DA8C1682\ntdll.pdb
Compiler: C++ - front end [13.10 bld 4035] - back end [13.10 bld
4035]
Load Report: private symbols & lines, source indexed
c:\LocalSymbols\ntdll.pdb\93E72E109DC84F16AA54797E4DA8C1682\ntdll.pdb
Hope it helps.
Yes, thanks for your help. Note that what I did was use the "strings"
command. This is a unix command which pulls out all the printable strings
from a file. You can use this (as well as many other unix shell commands)
on Windows with the help of cygwin (www.cygwin.com). So in my case, I was
able to do the below in a cygwin shell to list all source files contained in
the .PDB.
strings myfile.pdb | grep '.cpp'
.
- Follow-Ups:
- Re: unable to set breakpoint
- From: "Jeffrey Tan[MSFT]"
- Re: unable to set breakpoint
- References:
- Re: unable to set breakpoint
- From: "Jeffrey Tan[MSFT]"
- Re: unable to set breakpoint
- Prev by Date: Re: unable to set breakpoint
- Next by Date: Re: unable to set breakpoint
- Previous by thread: Re: unable to set breakpoint
- Next by thread: Re: unable to set breakpoint
- Index(es):
Relevant Pages
|
