Welcome to MSDN Blogs Sign in | Join | Help

It Goes to Eleven and ... to the NT Insider!

Well - for anyone bored enough to track such things, I have been pretty slammed lately and haven't blogged anything. I have a bunch of stuff queued up though. Upcoming posts (in the next few days hopefully) are:

1. The Anatomy of a Context Switch

2. The Anatomy of an Interrupt

3. The Anatomy of a Rootkit

Also – the guys over at OSR were nice enough to ask me to write an article for them. It is going to be in the March/April edition of the Insider.

I am also looking for topics of interest to the community at large if anyone has suggestions – please send them my way. Thanks!

Published Tuesday, April 29, 2008 1:03 AM by theelvez

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: It Goes to Eleven and ... to the NT Insider!

Hi jonathan,

Perhaps you can post about the abilities of modern optimizing compilers to reorganize code, especially around function calls. The current assumption of most developers is that compilers don't do tricks around function calls. However, new compilers do aggressive inlining and might do "clever" things because of that.

(I must say that this issue is bugging me for quite some time now because of your earlier posts...)

Consider the following code snippet:

IoMarkIrpPending(pIRP);

/*Do something to pend the IRP*/

pendIRP(pIRP);

return STATUS_PENDING;

If the compiler will move the IoMarkIrpPending line (Which is just a macro!!!) after the pendIRP function we will have a possible memory corruption. The usual assumption is that pendIRP uses pIRP and therefore the compiler cannot reorganize IoMarkIrpPending. But what if the compiler was smart enough to understand that pendIRP doesn't change and/or doesn't need anything that is changed by IoMarkIrpPending?

Thanks,

Eran.

Wednesday, April 30, 2008 1:15 AM by eranb

# re: It Goes to Eleven and ... to the NT Insider!

I like the way you think Eran! :D

You are correct in your paranoia - that the compiler can/will be able to do stuff like this in the future. The key thing is to analyze the code in the worst case scenario where it gets inlined. This makes you future proof even if the compiler changes underneath you. In the case of the queued irp - queueing usually implies a locked operation of some type which will create a barrier in the code. Does that make sense at all? :)

Thanks!

Tuesday, May 06, 2008 1:20 AM by theelvez

Leave a Comment

(required) 
required 
(required) 
 
Page view tracker