RE: ETW Level Flags question and bits question

NTDEV
1

Ok #1

There is a direct match between the names in the -func line and the
macro
-func:gsDebugPrintEx(LEVEL,FLAG,MSG,…)
Has FLAG
But
#define WPP_LEVEL_FLAGS_LOGGER(lvl,flags) WPP_LEVEL_LOGGER(flags)
Has FLAGS
Or was this a typo in the email? However from the error message I think
that this is the problem.

WPP creates these Macro names from the names assigned before “MSG”

#5
I see you want to actually use the value, I have never seen that request
before, were you looking to do something particular that maybe I’d
suggest a different option.

We don’t have a built in function to do this just now, but would the
following be reasonably self documenting.

I think what you would like would both
WPP_BIT_myflagname and myflagname defined
But the problem with that is that the pre-processor does substituions
after WPP and would mess up WPP_BIT_myflagname

How about
#define WPP_GET_VALUE(flag) WPP_BIT_ ## flag
And do
GlobalDebugType = WPP_GET_VALUE(flag1)

#6
That needs a bit more explanation, let me send in a follow on mail

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, February 16, 2004 12:09 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Moron ETW

Ian,

I haven’t really resolved much at all, other than the whitespace issue.

As I wrote originally:

  1. As far as I can tell, Henry’s hint about how to use the
    !UNDOCUMENTED!
    level and flag support in WPP does not work. If I amend my sources file
    as
    follows:

RUN_WPP=$(SOURCES) \
-km \
-func:gsDebugPrintEx(LEVEL,FLAG,MSG,…)

And add the following to a global include file:

#define WPP_LEVEL_FLAGS_LOGGER(lvl,flags) WPP_LEVEL_LOGGER(flags)

#define WPP_LEVEL_FLAGS_ENABLED(lvl,flags) \
(WPP_LEVEL_ENABLED(flags) && WPP_CONTROL(WPP_BIT_##flags).Level >=
lvl)

#define WPP_CONTROL_GUIDS \
WPP_DEFINE_CONTROL_GUID(someguid,\
(42F45982,818A,41dd,ADD3,DEB1A24DE686),\
WPP_DEFINE_BIT(flag1) \
WPP_DEFINE_BIT(flag2) \
)

I get the usual badness of the control bit flags being undefined. I also
get:

WPP_LEVEL_FLAG_ENABLED’: identifier not found, even with
argument-dependent
lookup

And

‘WPP_LEVEL_FLAG_LOGGER’: identifier not found, even with
argument-dependent
lookup

  1. the ‘munged flags’ (those under the control of WPP_DEFINE_BIT) cannot
    be
    used outside of calls to the munged function(s) defined in RUN_WPP. So
    for
    example having code that does something like:

GlobalDebugType = flag1;

Results in an error because flag1 us undefined. Badness! WPP ought to
generate the premunged flag1 names as valid symbols. Oddly, this feature
is
undocumented.

And my latest addition:

  1. My latest nightmare is how to expose log based debugging from a
    software
    library to the clients of that library. And once again this appears to
    be a
    bit on the undocumented side.

I am however intimately acquainted with error messages such as “error
C2065:
‘WPP_BIT_3’ : undeclared identifier” :slight_smile:

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Service
Sent: Monday, February 16, 2004 2:48 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Moron ETW

If you guys can post some of the specific questions I will
try and get them answered for you in as timely a fashion as possible.

Most you seem to have resolved yourselves, but let me know
what is outstanding?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Monday, February 16, 2004 11:32 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Moron ETW

> ----------
> From: xxxxx@hollistech.com[SMTP:xxxxx@hollistech.com]
> Reply To: xxxxx@lists.osr.com
> Sent: Monday, February 16, 2004 7:59 PM
> To: xxxxx@lists.osr.com
> Subject: RE: [ntdev] Moron ETW
>
> Well I havent’ given up yet, as I am a persistent son of a
bitch, but
it
> has
> so far been a fairly complete waste of time. As to why I bothered,
mostly
> it
> is because conceptually logging makes sense, and if Microsoft has
> implemented a generic logging facility that can readily be used for
kernel
> components, that makes even more sense.
>
Yes, I’m interested about it for equal reasons. In my
experience tracing is superior debugging technique for
anybody who doesn’t make beginners’
coding
errors. I’m eager to use generic logging facility but only if
everything I’m accustomed to use now can be done with it.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.com To unsubscribe send a blank
email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

2

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Service
Sent: Monday, February 16, 2004 3:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW Level Flags question and bits question

Ok #1

There is a direct match between the names in the -func line
and the macro
-func:gsDebugPrintEx(LEVEL,FLAG,MSG,…)
Has FLAG
But
#define WPP_LEVEL_FLAGS_LOGGER(lvl,flags)
WPP_LEVEL_LOGGER(flags) Has FLAGS Or was this a typo in the
email? However from the error message I think that this is
the problem.

WPP creates these Macro names from the names assigned before “MSG”

OK that sounds reasonable. However ‘direct match’ in this case would be
‘direct case-insensitive match’, which you probably find obvious, but I
certainly didn’t make the connection.

#5
I see you want to actually use the value, I have never seen
that request before, were you looking to do something
particular that maybe I’d suggest a different option.

We don’t have a built in function to do this just now, but
would the following be reasonably self documenting.

I think what you would like would both
WPP_BIT_myflagname and myflagname defined But the
problem with that is that the pre-processor does substituions
after WPP and would mess up WPP_BIT_myflagname

How about
#define WPP_GET_VALUE(flag) WPP_BIT_ ## flag
And do
GlobalDebugType = WPP_GET_VALUE(flag1)

That looks like it works. The point is that I am converting an existing
debugging system that does lots of nice things for me, including the ability
to turn on/off tracing by type and level at runtime, and consequently I have
code that sets global variables to type/level values, and this obviously
conflicts with the ETW assumptions.

#6
That needs a bit more explanation, let me send in a follow on mail

As Emily Latella would have said “nevermind”.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, February 16, 2004 12:09 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Moron ETW

Ian,

I haven’t really resolved much at all, other than the
whitespace issue.

As I wrote originally:

  1. As far as I can tell, Henry’s hint about how to use the
    !UNDOCUMENTED!
    level and flag support in WPP does not work. If I amend my
    sources file as
    follows:

RUN_WPP=$(SOURCES) \
-km \
-func:gsDebugPrintEx(LEVEL,FLAG,MSG,…)

And add the following to a global include file:

#define WPP_LEVEL_FLAGS_LOGGER(lvl,flags) WPP_LEVEL_LOGGER(flags)

#define WPP_LEVEL_FLAGS_ENABLED(lvl,flags) \
(WPP_LEVEL_ENABLED(flags) && WPP_CONTROL(WPP_BIT_##flags).Level >=
lvl)

#define WPP_CONTROL_GUIDS \
WPP_DEFINE_CONTROL_GUID(someguid,\
(42F45982,818A,41dd,ADD3,DEB1A24DE686),\
WPP_DEFINE_BIT(flag1) \
WPP_DEFINE_BIT(flag2) \
)

I get the usual badness of the control bit flags being
undefined. I also
get:

WPP_LEVEL_FLAG_ENABLED’: identifier not found, even with
argument-dependent lookup

And

‘WPP_LEVEL_FLAG_LOGGER’: identifier not found, even with
argument-dependent lookup

  1. the ‘munged flags’ (those under the control of
    WPP_DEFINE_BIT) cannot be used outside of calls to the munged
    function(s) defined in RUN_WPP. So for example having code
    that does something like:

GlobalDebugType = flag1;

Results in an error because flag1 us undefined. Badness! WPP
ought to generate the premunged flag1 names as valid symbols.
Oddly, this feature is undocumented.

And my latest addition:

  1. My latest nightmare is how to expose log based debugging
    from a software library to the clients of that library. And
    once again this appears to be a bit on the undocumented side.

I am however intimately acquainted with error messages such as “error
C2065:
‘WPP_BIT_3’ : undeclared identifier” :slight_smile:

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ian Service
> Sent: Monday, February 16, 2004 2:48 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Moron ETW
>
> If you guys can post some of the specific questions I will
try and get
> them answered for you in as timely a fashion as possible.
>
> Most you seem to have resolved yourselves, but let me know what is
> outstanding?
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
Michal Vodicka
> Sent: Monday, February 16, 2004 11:32 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Moron ETW
>
> > ----------
> > From: xxxxx@hollistech.com[SMTP:xxxxx@hollistech.com]
> > Reply To: xxxxx@lists.osr.com
> > Sent: Monday, February 16, 2004 7:59 PM
> > To: xxxxx@lists.osr.com
> > Subject: RE: [ntdev] Moron ETW
> >
> > Well I havent’ given up yet, as I am a persistent son of a
> bitch, but
> it
> > has
> > so far been a fairly complete waste of time. As to why I bothered,
> mostly
> > it
> > is because conceptually logging makes sense, and if Microsoft has
> > implemented a generic logging facility that can readily
be used for
> kernel
> > components, that makes even more sense.
> >
> Yes, I’m interested about it for equal reasons. In my experience
> tracing is superior debugging technique for anybody who
doesn’t make
> beginners’
> coding
> errors. I’m eager to use generic logging facility but only if
> everything I’m accustomed to use now can be done with it.
>
> Best regards,
>
> Michal Vodicka
> STMicroelectronics Design and Application s.r.o.
> [michal.vodicka@st.com, http:://www.st.com]
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@windows.microsoft.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.com To unsubscribe send a blank
email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com