Sorry for cross posting, ut my post at windbg was for the ppl who developed
it more than for a solution.
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??
can i on the fly in the debugger prompt define a DT and then use it to
typecast memory references??
–
–
Windbg is interpreting the output from the compiler. If the BLAH section is
compiled in for the version you are debugging, it will be displayed via dt.
If the BLAH section is not compiled in, it will not be displayed by the dt
command. Your explanation for what is happening is incorrect.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
Sent: Friday, February 23, 2007 10:19 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] ugly debugger problem
Sorry for cross posting, ut my post at windbg was for the ppl who developed
it more than for a solution.
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??
can i on the fly in the debugger prompt define a DT and then use it to
typecast memory references??
–
–
Have you ever looked at a struct with union embedded, then you could have
a reason to be confused, first time you look at it. But still windbg does
represent very correctly. Here what you seeing is simply does not make
sense. Depending on the define of BLAH, your struct would be one or the
other form, and it would be reflected when you look thru the debugger.
-pro
Sorry for cross posting, ut my post at windbg was for the ppl who
developed
it more than for a solution.
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??
can i on the fly in the debugger prompt define a DT and then use it to
typecast memory references??
–
–
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
like mark said, windbg knows nothing if #defines. I bet you what is happening is that you are not globally defining BLAH and that struct x is globally defined, so that some files contain the larger version of the struct x (with it BLAH defined with the added fields) and some files contain the smaller version without. In this case, the PDB will have conflicting entries about the same symbol type and windbg picks the first one. I bet if you ran an x !x* you would see 2 definitions
d
I think Doron your ans could be closer to my problem. I cannot off the cuff
tell you ppl what is that exactly is screwing up, it is a week end, and I
dnt have the code with me. It is a very large project and I need to
thoroughly go throug the defs first.
Will do so on monday, and get back!
On 2/23/07, xxxxx@microsoft.com wrote:
>
> like mark said, windbg knows nothing if #defines. I bet you what is
> happening is that you are not globally defining BLAH and that struct x is
> globally defined, so that some files contain the larger version of the
> struct x (with it BLAH defined with the added fields) and some files contain
> the smaller version without. In this case, the PDB will have conflicting
> entries about the same symbol type and windbg picks the first one. I bet if
> you ran an x !x* you would see 2 definitions
>
> d
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
- amitr0
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/23/07, amitr0 wrote:
>
> I think Doron your ans could be closer to my problem. I cannot off the
> cuff tell you ppl what is that exactly is screwing up, it is a week end, and
> I dnt have the code with me. It is a very large project and I need to
> thoroughly go throug the defs first.
>
> Will do so on monday, and get back!
>
>
>
>
> On 2/23/07, xxxxx@microsoft.com wrote:
> >
> > like mark said, windbg knows nothing if #defines. I bet you what is
> > happening is that you are not globally defining BLAH and that struct x is
> > globally defined, so that some files contain the larger version of the
> > struct x (with it BLAH defined with the added fields) and some files contain
> > the smaller version without. In this case, the PDB will have conflicting
> > entries about the same symbol type and windbg picks the first one. I bet if
> > you ran an x !x* you would see 2 definitions
> >
> > d
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
>
>
>
> –
>
> - amitr0
–
- amitr0
As was pointed out before, you have a bug. Bottom line is somewhere you
have BLAH undefined. Try temporarily commenting out the ifdef, and then
REBUILD ALL.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“amitr0” wrote in message news:xxxxx@ntdev…
> 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/23/07, amitr0 wrote:
>>
>> I think Doron your ans could be closer to my problem. I cannot off the
>> cuff tell you ppl what is that exactly is screwing up, it is a week end,
>> and
>> I dnt have the code with me. It is a very large project and I need to
>> thoroughly go throug the defs first.
>>
>> Will do so on monday, and get back!
>>
>>
>>
>>
>> On 2/23/07, xxxxx@microsoft.com
>> wrote:
>> >
>> > like mark said, windbg knows nothing if #defines. I bet you what is
>> > happening is that you are not globally defining BLAH and that struct x
>> > is
>> > globally defined, so that some files contain the larger version of the
>> > struct x (with it BLAH defined with the added fields) and some files
>> > contain
>> > the smaller version without. In this case, the PDB will have
>> > conflicting
>> > entries about the same symbol type and windbg picks the first one. I
>> > bet if
>> > you ran an x !x* you would see 2 definitions
>> >
>> > d
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>> >
>>
>>
>>
>> –
>>
>> - amitr0
>
>
>
>
> –
>
> - amitr0
>
o yeah, it works fine then!
On 2/26/07, Don Burn wrote:
>
> As was pointed out before, you have a bug. Bottom line is somewhere you
> have BLAH undefined. Try temporarily commenting out the ifdef, and then
> REBUILD ALL.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> “amitr0” wrote in message news:xxxxx@ntdev…
> > 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/23/07, amitr0 wrote:
> >>
> >> I think Doron your ans could be closer to my problem. I cannot off the
> >> cuff tell you ppl what is that exactly is screwing up, it is a week
> end,
> >> and
> >> I dnt have the code with me. It is a very large project and I need to
> >> thoroughly go throug the defs first.
> >>
> >> Will do so on monday, and get back!
> >>
> >>
> >>
> >>
> >> On 2/23/07, xxxxx@microsoft.com
> >> wrote:
> >> >
> >> > like mark said, windbg knows nothing if #defines. I bet you what is
> >> > happening is that you are not globally defining BLAH and that struct
> x
> >> > is
> >> > globally defined, so that some files contain the larger version of
> the
> >> > struct x (with it BLAH defined with the added fields) and some files
> >> > contain
> >> > the smaller version without. In this case, the PDB will have
> >> > conflicting
> >> > entries about the same symbol type and windbg picks the first one. I
> >> > bet if
> >> > you ran an x !x* you would see 2 definitions
> >> >
> >> > d
> >> >
> >> > —
> >> > Questions? First check the Kernel Driver FAQ at
> >> > http://www.osronline.com/article.cfm?id=256
> >> >
> >> > To unsubscribe, visit the List Server section of OSR Online at
> >> > http://www.osronline.com/page.cfm?name=ListServer
> >> >
> >>
> >>
> >>
> >> –
> >>
> >> - amitr0
> >
> >
> >
> >
> > –
> >
> > - amitr0
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
- amitr0
Is this component a library? are you refering to this structure in other libraries that you are linking against? BLAH has to be defined for the entire project across all libraries, otherwise you will have definition mismatches (and possibly some very fun memory corruption issues if the structure moves from lib to lib where BLAH’s definition changes).
d
And show us the way how you define BLAH in the SOURCES.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Don Burn[SMTP:xxxxx@acm.org]
Reply To: Windows System Software Devs Interest List
Sent: Monday, February 26, 2007 10:24 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] ugly debugger problem
As was pointed out before, you have a bug. Bottom line is somewhere you
have BLAH undefined. Try temporarily commenting out the ifdef, and then
REBUILD ALL.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“amitr0” wrote in message news:xxxxx@ntdev…
> > 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/23/07, amitr0 wrote:
> >>
> >> I think Doron your ans could be closer to my problem. I cannot off the
> >> cuff tell you ppl what is that exactly is screwing up, it is a week end,
> >> and
> >> I dnt have the code with me. It is a very large project and I need to
> >> thoroughly go throug the defs first.
> >>
> >> Will do so on monday, and get back!
> >>
> >>
> >>
> >>
> >> On 2/23/07, xxxxx@microsoft.com
> >> wrote:
> >> >
> >> > like mark said, windbg knows nothing if #defines. I bet you what is
> >> > happening is that you are not globally defining BLAH and that struct x
> >> > is
> >> > globally defined, so that some files contain the larger version of the
> >> > struct x (with it BLAH defined with the added fields) and some files
> >> > contain
> >> > the smaller version without. In this case, the PDB will have
> >> > conflicting
> >> > entries about the same symbol type and windbg picks the first one. I
> >> > bet if
> >> > you ran an x !x* you would see 2 definitions
> >> >
> >> > d
> >> >
> >> > —
> >> > Questions? First check the Kernel Driver FAQ at
> >> > http://www.osronline.com/article.cfm?id=256
> >> >
> >> > To unsubscribe, visit the List Server section of OSR Online at
> >> > http://www.osronline.com/page.cfm?name=ListServer
> >> >
> >>
> >>
> >>
> >> –
> >>
> >> - amitr0
> >
> >
> >
> >
> > –
> >
> > - amitr0
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>