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!


Comments (3)
  1. eranb says:

    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.

  2. theelvez says:

    I like the way you think Eran! 😀

    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!

  3. Aelthegrin says:

    I just subscribed to your blog and I think it’s great!

    You haven’t written anything since May, but please, post something about the topics you mentioned here, I’d love to hear more about it…

Comments are closed.

Skip to main content