none
Clarification needed with corhlpr.h RRS feed

  • Question

  • Hi All

    I have been messing with profiler API whilst working on an OpenSource code coverage tool called OpenCover.

    Now I have had to spend a lot of time on the header files and I have noticed something odd that I hope someone in the community could clarify for me.

    Q) When determining the difference between a Tiny header and a Fat header you use the 2 lower bits of the first byte and this is shown in the structures IMAGE_COR_ILMETHOD_FAT and IMAGE_COR_ILMETHOD_TINY but the methods used differ slightly and I don't understand why (probably missing the obvious)

    in IMAGE_COR_ILMETHOD_FAT we see

     

    bool IsFat() const {
            return (*(BYTE*)this & CorILMethod_FormatMask) == CorILMethod_FatFormat;
        }

     

    in IMAGE_COR_ILMETHOD_TINY we see

     

    bool     IsTiny() const         
        { 
            return((Flags_CodeSize & (CorILMethod_FormatMask >> 1)) == CorILMethod_TinyFormat); 
        }

     

    where

     

    CorILMethod_TinyFormat = 2
    CorILMethod_FatFormat = 3
    CorILMethod_FormatMask = 7

    Why isn't CorILMethod_FormatMask defined as 3?
    As it currently stands in the IsFat method it means that the lowest bit of the flags in the FAT header will always have to be 0 and the IsTiny method has to employ a shift operator to turn the 7 into a 3. Now the only reason I could see it being used is when dealing with CorILMethod_TinyFormat1 (defined as 6 and used for when the code size is odd) but I don't see any use of this enum in the header files (I am not saying there isn't I just can't find it through searching).
    Okay I understand that the compiler will probably optimise the shift out and that the numbers are due to some legacy thing but I whenever I look at these headers keep wondering if I am missing something and why it hasn't been simplified when other parts of the headers have had changes.
    Regards
    Shaun

     

    Saturday, May 7, 2011 3:35 AM

Answers

  • Hi,

    We don’t have access to the reasons why the code was written as it is. As you might understand, the decision tree for every line of code is not documented or otherwise captured. As you say, with an optimizing compiler, the generated code will be the same so there is really no reason to change it. Depending on when we are in a development cycle, single line changes can be either trivial and at the code owners discretion or they could require many meetings and buy-off from many stakeholders.


    bill boyce
    Thursday, May 12, 2011 11:36 AM
    Moderator

All replies

  • Hi Shaun,

     

    Thank you for your question, we're doing research on this case, it might take some time before we get back to you.


    Eric Yang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, May 9, 2011 2:20 AM
  • Hi,

    We don’t have access to the reasons why the code was written as it is. As you might understand, the decision tree for every line of code is not documented or otherwise captured. As you say, with an optimizing compiler, the generated code will be the same so there is really no reason to change it. Depending on when we are in a development cycle, single line changes can be either trivial and at the code owners discretion or they could require many meetings and buy-off from many stakeholders.


    bill boyce
    Thursday, May 12, 2011 11:36 AM
    Moderator
  • Thanks for the update

    I largely thought it was something legacy like that my C++ is rather rusty and I keep wondering if it is some weird C(++) trick that I am missing.

    Friday, May 13, 2011 4:05 AM