Share via

Who's the guy with the nifty haircut?

  • Article

Howdy!  I'm David Broman, and I've been a developer on the Common Language Runtime for about a year, focusing on the Profiling API with Jonathan Keljo, Rico Mariani, and many others.

Before the CLR, I worked in various MSN groups, including the MSN Newsletters system.  (Sign up for your free email newsletters now!), and the now-defunct Sidewalk--anyone remember Sidewalk?  Before that I worked on Visual C++ versions 1.5 through 5.0.  Rico's history intersects with my own for quite a few of these teams.

When I'm not at work, I enjoy thinking about work, obsessing about what I'll do when I get to work, and I enjoy working from home.  Ok, it's not really that bad.  :-)  I also enjoy playing piano and writing and recording music.  Sometimes I'll even have multiple Daves attempting to sing in harmony with each other on topics as crucial as riding the airport shuttle or eating salad.  Don't worry, I'm not about to quit my day job.

I grew up in South Florida and became accustomed to almost year-round humid heat.  The Seattle area is beautiful and moderate, but sometimes I miss those days where you exit a building to the hot parking lot, and then enter your sun-baked car where it's even hotter.  We just don't get that kind of heat out here.  Most people consider that a blessing, but I miss it!

Anyway, the profiling API team is spending a lot of time contributing content for the CLR 2.0 profiling API documentation.  I plan to blog here some of the topics I'll be contributing (before they're potentially sanitized of all personality for inclusion in the overall documentation set), as well as other tidbits of use to anyone consuming the CLR profiling API.

Many of you profiler writers who are working off of betas of CLR 2.0 have been in the dark to some extent, as our documentation is still growing.  I'm hoping to shed some light on your work now, so you don't have to wait until we RTM to discover you've been using our API all wrong.  :-)  By the way, you'll definitely want to be reading Jonathan's blog as well, if you're not already.

Please let me know what you think about my posts, and if there are other topics you'd like discussed.

Comments

  • Anonymous
    February 05, 2006
    Hi David,

    I am trying to use the Profiling API to trace all function calls and function arguments/return values an application performs.

    But I have problems getting the function return values of functions returning value types. The given address of the return value is sometimes shifted by the length of the value type, like an unwanted stack shift.

    In case of function TestGood() and function TestGood2() (see below) the profiling API passes the correct address of the return value.

    But for TestBad() the profiling API provides an address that is decreased by the length (0x10) of the newly created value type.

    Did I do anything wrong accessing the values or is this a known issue ?

    public class DefectTestDecimal
    {
    Decimal myValue = 0xabcdef;

    public System.Decimal TestGood()
    {
     return myValue;
    }

    public System.Decimal TestBad()
    {
     Decimal result = new Decimal(0x12345678);
     return result;
    }

    public System.Decimal TestGood2()
    {
     Decimal tmp2= new Decimal(0x12345678);
     Decimal result = new Decimal(0x12345678);
     return result;
    }
    }

    Kind regards,
    Holger
  • Anonymous
    February 07, 2006
    My guess here is that you're seeing the difference between a value type being boxed or unboxed.  In the former case, there will be an offset you'll need to apply to get to the value.  (I believe 0x10 ends up being the offset you'd normally see on a 64 bit machine.)  In the latter, no offset need be applied.  What's strange, though, is I don't see why your particular example would cause any boxing.  If, for example, TestBad() was typed as returning an Object rather than a Decimal, then the Decimal would be boxed before being returned.  I can only guess that there might be part of your scenario I'm not seeing that might cause the boxing...?

    In general, the metadata will tell you whether the return type is an object or not.  If it is an Object, GetClassFromObject() will help you find the Class, and then GetBoxClassLayout() will give you the offset you need to apply to get down to the value.  Note that GetBoxClassLayout() will return an error if you give it a non-value type class.  This makes it a handy function to use to determine if a Class is a value type or not.

    Please let me know if this helps.
  • Anonymous
    February 23, 2006
    After further investigation, it's clear Holger has indeed run into a bug in the CLR.  I will be posting an entry describing this in detail.
  • Anonymous
    February 27, 2006
    The new entry on this has been posted:
    http://blogs.msdn.com/davbr/archive/2006/02/27/540280.aspx