Re: 1. To say this for the third time, yes, this is your problem. You have to manually look at the disassembly to figure out where things are - end of story.
Re: 2. I don’t know the specifics of the internal representation, but one assumes that there is a table somewhere that maps address ranges to a particular source file and line number. The .pdb debug info format is not documented.
The debugger uses DbgHelp for retrieving this information from symbol files. If you are interested in how those APIs are defined, then you need to go look at the DbgHelp documentation in MSDN. You will get more useful information from reading that documentation than asking here about how to work with symbols on your own.
-----Original Message-----
From: Lin George
Sent: Thursday, September 25, 2008 07:56
To: Skywing
Cc: Kernel Debugging Interest List
Subject: Re: [windbg] Debugging issue to watch variable values
Thanks Skywing,
1.
So you think my issue of watching variables in release x64 mode with optimized code is, PDB file has limitation which could not correctly reflects the values in registers?
2.
I am interested in how debugger could utilize information in PDB file to find related symbol related to some binary code. And also how to find related source code. I have made quite some search, but few good documents/articles. Do you have any of such materials to recommend to read?
regards,
George
----- Original Message ----
From: Skywing
To: Kernel Debugging Interest List
Cc: Kernel Debugging Interest List
Sent: Thursday, September 25, 2008 8:49:28 PM
Subject: RE: [windbg] Debugging issue to watch variable values
To reiterate what I said earlier, as far as I know, the debug info format’s support for locals is based on the assumption that they are stack based.
This is a limitation of the current tools, and not so much of any fundamental technical roadblock aside from the fact that it’s not how things were written to work.
This is why debug builds always try and put locals on the stack instead of exclusively saving them in a register.
The .pdb is built at code generation time. Think of it as reflecting a view of locals before the optimizer has had a chance to figure out that some locals do not need to live on the stack at all, but may reside exclusively in a register.
- S
-----Original Message-----
From: Lin George
Sent: Thursday, September 25, 2008 01:07
To: Skywing
Cc: Kernel Debugging Interest List
Subject: Re: [windbg] Debugging issue to watch variable values
Thanks Skywing,
1.
I think PDB is generated at compile/link time, correct?
I listed my confusions in 2 and 3, but I do not know which one is correct. Any comments?
2.
If yes to 1, then during compile/link time, whether variable will be put on stack or in register is still not decided, only during runtime will the location (whether variable on stack or in register) be decided. – So that the generated PDB is not matching the exact situation (e.g. PDB may think some variable on stack, but actually it is in register), which cause the wrong variable value during debugging?
3.
If yes to 1, then during compile/link time, whether variable will be put on stack or in register is still be decided, but PDB will completely ignore such information in register. – So that the generated PDB is not matching the exact situation (e.g. PDB may think some variable on stack, but actually it is in register), which cause the wrong variable value during debugging?
regards,
George
----- Original Message ----
From: Skywing
To: Kernel Debugging Interest List
Cc: Kernel Debugging Interest List
Sent: Thursday, September 25, 2008 1:11:17 PM
Subject: RE: [windbg] Debugging issue to watch variable values
.pdb is the debug file information format which contains symbol and type info (including line number mappings) for a binary.
As far as I know, the current .pdb formats only describe locals in terms of stack locations and not registers. Thus, for locals (including function arguments) that get moved into registers, this fact is not recorded in a usable way that would allow the debugger to track this.
The bottom line is that when you have parameters and locals being moved into registers, they will not show correct values in the local variable display in the debugger. The only guaranteed reliable way to do it is to look at the actual disassembly and figure out what variables are going where.
- S
-----Original Message-----
From: Lin George [mailto:xxxxx@yahoo.com]
Sent: Thursday, September 25, 2008 12:50 AM
To: Skywing
Cc: Kernel Debugging Interest List
Subject: Re: [windbg] Debugging issue to watch variable values
Hi Skywing,
1.
My confusion is what is the relationshp between PDB and source code, in what mechanisms do PDB and source code establish mapping relationship?
2.
“This is because PDB does not allow reliable tracking of variables that get cached in registers” – I always think PDB is 100% match binary even if optimized code, but seems not?
regards,
George
----- Original Message ----
From: Skywing
To: Kernel Debugging Interest List
Sent: Wednesday, September 24, 2008 9:58:05 PM
Subject: RE: [windbg] Debugging issue to watch variable values
This is because PDB does not allow reliable tracking of variables that get cached in registers.
You should be analyzing the code manually in this case.
Local variable support is only reliable when you are doing source line stepping in a non-optimized debug build.
- S
-----Original Message-----
From: Lin George
Sent: Wednesday, September 24, 2008 05:09
To: Kernel Debugging Interest List
Subject: [windbg] Debugging issue to watch variable values
Hello everyone,
1.
Sometimes in x64 release code (optimized to full level), even if we defined some global data, variables or member variables for some data structures, we can not see the actual value in debugger. The related error message is – “Error: expression cannot be evaluated”.
I think it is because of x64 code optimization to remove some variables or changed code execution path?
2.
Any ways to “watch” such variables? Currently I am just looking at the asembly code to find what the actual execution is. For example, in source code I pass variable foo to function SetValue, but since in debugger I can not watch such variable foo, then I go to assembly code to watch what values are passed to function SetValue through register or stack.
Any better ideas to debug such x64 optimized code? Is it a common issue in debugging x64 release code?
thanks in advance,
George
—
You are currently subscribed to windbg as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
