Are functions ALWAYS placed in non-paged memory unless specified to be put else where via alloc_text(PAGE,…)?
Yes the default is non-paged.
–
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
wrote in message news:xxxxx@ntdev…
> Are functions ALWAYS placed in non-paged memory unless specified to be put
> else where via alloc_text(PAGE,…)?
>
>
>
Correct - all driver code goes, by default, to unpageable TEXT section, apart from DriverEntry()
that normally goes to INIT section (it gets discarded from RAM after driver gets initialized). If you want your code to be pageable, you have to explicitly* marked as such, so that it will go to PAGE section. If there are some other functions that are needed only upon driver initialization, you can put them in INIT as well…
Anton Bassov
Yes that is true.
-pro
On Jan 18, 2008 8:39 AM, wrote:
> Are functions ALWAYS placed in non-paged memory unless specified to be put
> else where via alloc_text(PAGE,…)?
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Quite true. Two small things to add. The first is that, if you’re
evaluating existing code, something to keep in mind is that these
directives can be buried in header files. I realize this is pretty
obvious, but I find the vast majority of the time, they aren’t in a
header file, and I have been surprised a few times by getting lazy and
just looking at top of a source file. The second is that if you’re
including C++ in the discussion, for some of its features like virtual
destructors, it is at least in theory not necessarily the case, as you
have no control over where they get placed. I’ve never seen anything
unusual happen, but just for completeness, I include it here, because
only the compiler implementors know the answer to this, strictly speaking.
Good luck,
mm
Don Burn wrote:
Yes the default is non-paged.
Martin O’Brien wrote:
Quite true. Two small things to add. The first is that, if you’re
evaluating existing code, something to keep in mind is that these
directives can be buried in header files. I realize this is pretty
obvious, but I find the vast majority of the time, they aren’t in a
header file, and I have been surprised a few times by getting lazy and
just looking at top of a source file. The second is that if you’re
including C++ in the discussion, for some of its features like virtual
destructors, it is at least in theory not necessarily the case, as you
have no control over where they get placed. I’ve never seen anything
unusual happen, but just for completeness, I include it here, because
only the compiler implementors know the answer to this, strictly
speaking.
Virtual functions are not a problem. They have bodies, so they can be
controlled with the #pragmas.
The problem with kernel C++ is template functions. They cause code to
be generated by the compiler, and the placement of that generated code
cannot currently be controlled. The empirical evidence suggests that
they are placed in whatever #pragma section was in effect at the end of
the source file, but no one will certify that.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Yes
#pragma alloc_text or #pragma code_seg can influence this.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Are functions ALWAYS placed in non-paged memory unless specified to be put
else where via alloc_text(PAGE,…)?
>
>
>
Tim:
You’re certainly correct about templates, but I don’t believe what you
say is correct in some situations in the case of virtual destructors.
But, before Before I go there, to make sure I’m not just missing
something, what #pragma’s do you use? code_seg and/or init_seg?
Thanks,
mm
Tim Roberts wrote:
Martin O’Brien wrote:
> Quite true. Two small things to add. The first is that, if you’re
> evaluating existing code, something to keep in mind is that these
> directives can be buried in header files. I realize this is pretty
> obvious, but I find the vast majority of the time, they aren’t in a
> header file, and I have been surprised a few times by getting lazy and
> just looking at top of a source file. The second is that if you’re
> including C++ in the discussion, for some of its features like virtual
> destructors, it is at least in theory not necessarily the case, as you
> have no control over where they get placed. I’ve never seen anything
> unusual happen, but just for completeness, I include it here, because
> only the compiler implementors know the answer to this, strictly
> speaking.Virtual functions are not a problem. They have bodies, so they can be
controlled with the #pragmas.The problem with kernel C++ is template functions. They cause code to
be generated by the compiler, and the placement of that generated code
cannot currently be controlled. The empirical evidence suggests that
they are placed in whatever #pragma section was in effect at the end of
the source file, but no one will certify that.
I thought that the problem is with C++ generated code of any sort -
templates or implied ctors/dtors. “The problem” is often mentioned,
but in my experience never manifested. I tend to not page out any of
my driver code anyhow, which reduces the potential for experiencing
the dreaded wrong segment error.
(With any luck this thread can go down that dreaded worm hole that
ends up with Peter yelling at Anton.)
On Jan 18, 2008 4:00 PM, Martin O’Brien wrote:
> Tim:
>
> You’re certainly correct about templates, but I don’t believe what you
> say is correct in some situations in the case of virtual destructors.
> But, before Before I go there, to make sure I’m not just missing
> something, what #pragma’s do you use? code_seg and/or init_seg?
>
> Thanks,
>
> mm
> Tim Roberts wrote:
> > Martin O’Brien wrote:
> >> Quite true. Two small things to add. The first is that, if you’re
> >> evaluating existing code, something to keep in mind is that these
> >> directives can be buried in header files. I realize this is pretty
> >> obvious, but I find the vast majority of the time, they aren’t in a
> >> header file, and I have been surprised a few times by getting lazy and
> >> just looking at top of a source file. The second is that if you’re
> >> including C++ in the discussion, for some of its features like virtual
> >> destructors, it is at least in theory not necessarily the case, as you
> >> have no control over where they get placed. I’ve never seen anything
> >> unusual happen, but just for completeness, I include it here, because
> >> only the compiler implementors know the answer to this, strictly
> >> speaking.
> >
> > Virtual functions are not a problem. They have bodies, so they can be
> > controlled with the #pragmas.
> >
> > The problem with kernel C++ is template functions. They cause code to
> > be generated by the compiler, and the placement of that generated code
> > cannot currently be controlled. The empirical evidence suggests that
> > they are placed in whatever #pragma section was in effect at the end of
> > the source file, but no one will certify that.
> >
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
–
Mark Roddy
Mark,
(With any luck this thread can go down that dreaded worm hole that
ends up with Peter yelling at Anton.)
No way - I am going to stay out of it, at least for the time being. In actuality, I am not that much interested in C vs C++ topic anyway - it is more of Alberto’s, rather than mine, favorites. . However, if it somehow turns to OS design issues, them apparently, I will have to try really hard to fight a temptation of joining …
Anton Bassov
>> (With any luck this thread can go down that dreaded worm
> hole that ends up with Peter yelling at Anton.)
No way - I am going to stay out of it, at least for the time being.
In actuality, I am not that much interested in C vs C++ topic anyway
LOL…
I’m staying out of this one too… at least for now.
Peter
OSR
(P.S. C++ is shit – Sorry, I couldn’t resist)
Martin O’Brien wrote:
You’re certainly correct about templates, but I don’t believe what you
say is correct in some situations in the case of virtual destructors.
But, before Before I go there, to make sure I’m not just missing
something, what #pragma’s do you use? code_seg and/or init_seg?
Right. Actually, I think Mark got it right: it isn’t virtual
destructors that cause trouble, but rather the automatic constructors
and destructors that the compiler generates when you don’t include one.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Note that there is also MmPageEntireDriver which places driver code in paged
memory at runtime.
/Daniel
wrote in message news:xxxxx@ntdev…
> Are functions ALWAYS placed in non-paged memory unless specified to be put
> else where via alloc_text(PAGE,…)?
>
>
>
> Note that there is also MmPageEntireDriver which places driver code in
paged memory at runtime.
Totally unrelated thing…
This is how loading drivers with NtSetSystemInformation() works - it loads a driver in the caller’s address space, and pages it to the disk. However, this is quite different driver - it receives
both NULLs in its DriverEntry(), so that it does not even have its driver object. Therefore, it cannot create devices, it cannot register handlers, and, in general, has very limited functionality…
Anton Bassov.
You recently offered to open up a new group called nttalk for discussing
tangentials. What has become of the idea,
did you drop it or was it never a serious propsal ?
Personally I found the discussions of Alberto and Anton very valuable so
it’s a bit of a pity these have gone.
/Daniel
wrote in message news:xxxxx@ntdev…
> LOL…
>
> I’m staying out of this one too… at least for now.
>
> Peter
> OSR
>
> (P.S. C++ is shit – Sorry, I couldn’t resist)
>
>
wrote in message news:xxxxx@ntdev…
>> Note that there is also MmPageEntireDriver which places driver code in
>> paged memory at runtime.
>
> Totally unrelated thing…
>
> This is how loading drivers with NtSetSystemInformation() works - it loads
> a driver in the caller’s address space, and pages it to the disk. However,
> this is quite different driver - it receives
> both NULLs in its DriverEntry(), so that it does not even have its driver
> object. Therefore, it cannot create devices, it cannot register handlers,
> and, in general, has very limited functionality…
>
> Anton Bassov.
>
>
From the MSDn description this is just a function you can call which puts
driver code in paged memory. I wasn’t talking about loading drivers with
NtSetSystemInformation or whatever you are talking about.
/Daniel
> From the MSDn description this is just a function you can call which puts driver
code in paged memory. I wasn’t talking about loading drivers with
NtSetSystemInformation or whatever you are talking about.
Imagine that you have done it to a “normal” driver that is attached to some stack. What is going to happen if driver above calls any of your Dispatch routines at DPC level??? Therefore, in practical terms, you wouldl use it only with those drivers of functionality comparable to the ones loaded with NtSetSystemInformation() - this is not the kind of thing you would use with “normal” drivers…
Anton Bassov
wrote in message news:xxxxx@ntdev…
…
> (P.S. C++ is shit – Sorry, I couldn’t resist)
Then what - c# ?
Regards,
–PA
Look at the serial sample driver for use of this function in a pnp (and “normal”) driver.
d
-----Original Message-----
From: “xxxxx@hotmail.com”
To: “Windows System Software Devs Interest List”
Sent: 01/19/08 12:09 AM
Subject: RE:[ntdev] function placement…
> From the MSDn description this is just a function you can call which puts driver
> code in paged memory. I wasn’t talking about loading drivers with
> NtSetSystemInformation or whatever you are talking about.
Imagine that you have done it to a “normal” driver that is attached to some stack. What is going to happen if driver above calls any of your Dispatch routines at DPC level??? Therefore, in practical terms, you wouldl use it only with those drivers of functionality comparable to the ones loaded with NtSetSystemInformation() - this is not the kind of thing you would use with “normal” drivers…
Anton Bassov
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Pavel A. wrote:
> (P.S. C++ is shit – Sorry, I couldn’t resist)
Then what - c# ?
I got into C# in the last six months and it’s a dream, especially compared to C++. (Does that make me a shill? I’ll take my MVP now, please!) I had to go back to C++ very recently for a project and it was mentally painful.