hi all,
i am facing an ugly problem in Windbg.
Say I have a struct like…
struct x{
int i;
char k;
#ifdef BLAH
char s[12];
float f;
#endif
char p[122];
};
Ok so when i compile this guy and try debugging, what happens is that windbg
doesnt seem to recognise the #ifdef in it and when it casts some memory
location to this struct it does it on the entire struct all the time.
causing to map wrong symbols to wrong places.
this is ugly.
is there a fix to this??
–
Hello Amitr.
I have compiled your code and ran it under windbg. The debugger
displayed the structure just fine…
0:000> dt x
dbh!x
+0x000 i : Int4B
+0x004 k : Char
+0x005 p : [122] Char
My suspicion is that you have the same structure is included in another
source file in the same module, only with BLAH defined. In this case,
the pdb file contains two entries for the structure in the type
information. When the debugger requests the type information from the
pdb, the first one is returned. In this case, it is impossible to
determine which version of the type information will be returned to the
debugger and you see the problem you experienced.
So in summary, this is a limitation of the debugger. We will look into
seeing what can be done about this, but I suspect there is not much or
we might have handled this in existing code.
.pat styles [microsoft]
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
Sent: Friday, February 23, 2007 7:17 PM
To: Kernel Debugging Interest List
Subject: [windbg] windbg 6.6 struct pasrwe problem
hi all,
i am facing an ugly problem in Windbg.
Say I have a struct like…
struct x{
int i;
char k;
#ifdef BLAH
char s[12];
float f;
#endif
char p[122];
};
Ok so when i compile this guy and try debugging, what happens is that
windbg doesnt seem to recognise the #ifdef in it and when it casts some
memory location to this struct it does it on the entire struct all the
time. causing to map wrong symbols to wrong places.
this is ugly.
is there a fix to this??
–
— You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I should add one more thing.
As I said, the debugger is unable to differentiate the two instances of
a type that has the same name, but in different source files. However
this does not apply to variables of these types. If you examine an
actual variable that is an instance of one of these types, it will show
the correct information. Example:
0:000> dt strct
Local var @ 0x7fffff8fe90 Type structure
+0x000 i : 2
+0x004 k : 0 ‘’
+0x005 p : [122] “”
0:000> dt strct
Local var @ 0x7fffff8fdb0 Type structure
+0x000 i : 0
+0x004 k : 0 ‘’
+0x005 s : [12] “”
+0x014 f : 0
+0x018 p : [122] “???”
I examined these two variables that were instantiated in different parts
of the code with the #define statement used to change the type. This
was the source…
struct structure
{
int i;
char k;
#ifdef BLAH
char s[12];
float f;
#endif
char p[122];
};
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pat Styles
Sent: Saturday, February 24, 2007 1:06 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] windbg 6.6 struct pasrwe problem
Hello Amitr.
I have compiled your code and ran it under windbg. The debugger
displayed the structure just fine…
0:000> dt x
dbh!x
+0x000 i : Int4B
+0x004 k : Char
+0x005 p : [122] Char
My suspicion is that you have the same structure is included in another
source file in the same module, only with BLAH defined. In this case,
the pdb file contains two entries for the structure in the type
information. When the debugger requests the type information from the
pdb, the first one is returned. In this case, it is impossible to
determine which version of the type information will be returned to the
debugger and you see the problem you experienced.
So in summary, this is a limitation of the debugger. We will look into
seeing what can be done about this, but I suspect there is not much or
we might have handled this in existing code.
.pat styles [microsoft]
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
Sent: Friday, February 23, 2007 7:17 PM
To: Kernel Debugging Interest List
Subject: [windbg] windbg 6.6 struct pasrwe problem
hi all,
i am facing an ugly problem in Windbg.
Say I have a struct like…
struct x{
int i;
char k;
#ifdef BLAH
char s[12];
float f;
#endif
char p[122];
};
Ok so when i compile this guy and try debugging, what happens is that
windbg doesnt seem to recognise the #ifdef in it and when it casts some
memory location to this struct it does it on the entire struct all the
time. causing to map wrong symbols to wrong places.
this is ugly.
is there a fix to this??
–
— You are currently subscribed to windbg as: xxxxx@microsoft.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
hi pat,
ok going back to my previous problem, i did analyze the code a bit. Look
like the BLAH is defined in the sources file not in the .c code files.
Now what happens is, Windbg picks up the shorted version of the struct
(without the #ifdef part) even if during compilation we have defined the
BLAH in sources!
amitr0
On 2/24/07, Pat Styles wrote:
>
> I should add one more thing.
>
>
>
> As I said, the debugger is unable to differentiate the two instances of a
> type that has the same name, but in different source files. However this
> does not apply to variables of these types. If you examine an actual
> variable that is an instance of one of these types, it will show the correct
> information. Example:
>
>
>
> 0:000> dt strct
>
> Local var @ 0x7fffff8fe90 Type structure
>
> +0x000 i : 2
>
> +0x004 k : 0 ‘’
>
> +0x005 p : [122] “”
>
>
>
> 0:000> dt strct
>
> Local var @ 0x7fffff8fdb0 Type structure
>
> +0x000 i : 0
>
> +0x004 k : 0 ‘’
>
> +0x005 s : [12] “”
>
> +0x014 f : 0
>
> +0x018 p : [122] “???”
>
>
>
> I examined these two variables that were instantiated in different parts
> of the code with the #define statement used to change the type. This was
> the source?
>
>
>
> struct structure
>
> {
>
> int i;
>
> char k;
>
> #ifdef BLAH
>
> char s[12];
>
> float f;
>
> #endif
>
> char p[122];
>
> };
>
>
>
>
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *Pat Styles
> Sent: Saturday, February 24, 2007 1:06 PM
> To: Kernel Debugging Interest List
> Subject: RE: [windbg] windbg 6.6 struct pasrwe problem
>
>
>
> Hello Amitr.
>
>
>
> I have compiled your code and ran it under windbg. The debugger displayed
> the structure just fine?
>
>
>
> 0:000> dt x
>
> dbh!x
>
> +0x000 i : Int4B
>
> +0x004 k : Char
>
> +0x005 p : [122] Char
>
>
>
> My suspicion is that you have the same structure is included in another
> source file in the same module, only with BLAH defined. In this case, the
> pdb file contains two entries for the structure in the type information.
> When the debugger requests the type information from the pdb, the first one
> is returned. In this case, it is impossible to determine which version of
> the type information will be returned to the debugger and you see the
> problem you experienced.
>
>
>
> So in summary, this is a limitation of the debugger. We will look into
> seeing what can be done about this, but I suspect there is not much or we
> might have handled this in existing code.
>
>
>
> .pat styles [microsoft]
>
>
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *amitr0
> Sent: Friday, February 23, 2007 7:17 PM
> To: Kernel Debugging Interest List
> Subject: [windbg] windbg 6.6 struct pasrwe problem
>
>
>
> hi all,
>
>
>
> i am facing an ugly problem in Windbg.
>
>
>
> Say I have a struct like…
>
>
>
>
>
> struct x{
>
> int i;
>
> char k;
>
>
>
> #ifdef BLAH
>
> char s[12];
>
> float f;
>
> #endif
>
> char p[122];
>
> };
>
>
>
>
>
> Ok so when i compile this guy and try debugging, what happens is that
> windbg doesnt seem to recognise the #ifdef in it and when it casts some
> memory location to this struct it does it on the entire struct all the time.
> causing to map wrong symbols to wrong places.
>
>
>
> this is ugly.
>
>
>
> is there a fix to this??
>
>
>
>
>
> –
>
> - amitr0
>
> — You are currently subscribed to windbg as: xxxxx@microsoft.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
>
–
- amitr0
Hello Amitr.
WinDbg can only show you what the compiler emitted into the pdb file. I
am pretty confident that the shortened version of the structure is
indeed, what is in the symbols. Sounds like a compiler or more likely,
a build issue.
.p
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
Sent: Monday, February 26, 2007 1:21 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] windbg 6.6 struct pasrwe problem
hi pat,
ok going back to my previous problem, i did analyze the code a bit. Look
like the BLAH is defined in the sources file not in the .c code files.
Now what happens is, Windbg picks up the shorted version of the struct
(without the #ifdef part) even if during compilation we have defined the
BLAH in sources!
amitr0
On 2/24/07, Pat Styles wrote:
I should add one more thing.
As I said, the debugger is unable to differentiate the two instances of
a type that has the same name, but in different source files. However
this does not apply to variables of these types. If you examine an
actual variable that is an instance of one of these types, it will show
the correct information. Example:
0:000> dt strct
Local var @ 0x7fffff8fe90 Type structure
+0x000 i : 2
+0x004 k : 0 ‘’
+0x005 p : [122] “”
0:000> dt strct
Local var @ 0x7fffff8fdb0 Type structure
+0x000 i : 0
+0x004 k : 0 ‘’
+0x005 s : [12] “”
+0x014 f : 0
+0x018 p : [122] “???”
I examined these two variables that were instantiated in different parts
of the code with the #define statement used to change the type. This
was the source…
struct structure
{
int i;
char k;
#ifdef BLAH
char s[12];
float f;
#endif
char p[122];
};
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pat Styles
Sent: Saturday, February 24, 2007 1:06 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] windbg 6.6 struct pasrwe problem
Hello Amitr.
I have compiled your code and ran it under windbg. The debugger
displayed the structure just fine…
0:000> dt x
dbh!x
+0x000 i : Int4B
+0x004 k : Char
+0x005 p : [122] Char
My suspicion is that you have the same structure is included in another
source file in the same module, only with BLAH defined. In this case,
the pdb file contains two entries for the structure in the type
information. When the debugger requests the type information from the
pdb, the first one is returned. In this case, it is impossible to
determine which version of the type information will be returned to the
debugger and you see the problem you experienced.
So in summary, this is a limitation of the debugger. We will look into
seeing what can be done about this, but I suspect there is not much or
we might have handled this in existing code.
.pat styles [microsoft]
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
Sent: Friday, February 23, 2007 7:17 PM
To: Kernel Debugging Interest List
Subject: [windbg] windbg 6.6 struct pasrwe problem
hi all,
i am facing an ugly problem in Windbg.
Say I have a struct like…
struct x{
int i;
char k;
#ifdef BLAH
char s[12];
float f;
#endif
char p[122];
};
Ok so when i compile this guy and try debugging, what happens is that
windbg doesnt seem to recognise the #ifdef in it and when it casts some
memory location to this struct it does it on the entire struct all the
time. causing to map wrong symbols to wrong places.
this is ugly.
is there a fix to this??
–
- amitr0
— You are currently subscribed to windbg as: xxxxx@microsoft.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
–
- amitr0 — You are currently subscribed to windbg as: unknown lmsubst
tag argument: ‘’ To unsubscribe send a blank email to
xxxxx@lists.osr.com