[clr-interp][debugging] Use address of opcode instead of interpreter precode in dji.m_addrOfCode

[matouskozak]

From: #123251 (comment)

Having a field called m_addrOfCode that doesn't point to the first instruction is unexpected and breaks the invariant all the other jitted code has. Typically in the runtime any type that is PCODE or methods/fields expressly named "Code" with a neutral type such CORDB_ADDRESS, TADDR, void* means a pointer to an opcode. When the runtime wants to point to a header in front of those opcodes we use a different explicit type like CodeHeader.

struct CodeHeader
{
    PTR_RealCodeHeader   pRealCodeHeader;
    ...
    TADDR                   GetCodeStartAddress()
    {
        return dac_cast<PCODE>(dac_cast<PTR_CodeHeader>(this) + 1);
    }

We should strongly consider using the address of the opcodes and not the address of the header everywhere we refer to the abstraction as being 'code' or 'bytecode'. In addition to the potential for the confusion to cause runtime bugs and interpreter special casing, these pointers also get exported outside the runtime via PerfMaps, ETW events, EventPipe events, ICorProfiler APIs, and ICorDebug APIs. Its entirely possible that some diagnostic tools will start looking at the memory present at the code pointer which means the header becomes part of the de-facto diagnostics contract for interpreter code and it is difficult to change. We usually try to keep these implicit interfaces between diagnostic tools and the runtime as free of extraneous implementation details as possible.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.