Addresses and call instructions

  • Thread starter Thread starter John
  • Start date Start date
J

John

Hi all,

Maybe someone could help me clearing out some confusion.

If I compile the following lines of code and break the execution with
a debugger just after the call to a(), but before the call to b(), i
would expect the calls to jump to memory locations in usermode address
space, however, from the assembly listing below, I see call
instructions to addresses way up in the address space.

Can anyone explain this?

Thanx!

John.


namespace ConsoleApplication2
{
class Program
{
static void Main(string[] args)
{
Bob.f();
}
}

static class Bob
{
public static void a() { Console.WriteLine("a"); }
public static void b() { Console.WriteLine("b"); }
public static void c() { Console.WriteLine("b"); }
public static void f() { a(); b(); c(); }
}
}



00000000 sub rsp,28h
00000004 nop
00000005 mov rax,7FF001D1D60h
0000000f mov eax,dword ptr [rax]
00000011 test eax,eax
00000013 je 000000000000001A
00000015 call FFFFFFFFF305F4B0
0000001a nop
0000001b call FFFFFFFFFFEC9378
00000020 nop
00000021 call FFFFFFFFFFEC9380
00000026 nop
00000027 call FFFFFFFFFFEC9388
0000002c nop
0000002d jmp 000000000000002F
0000002f add rsp,28h
00000033 rep ret
 
Hi John,

The short and sweet is that the Visual Studio debugger is not showing you
the correct values. Too be honest I have not done any of this on a 64 bit
platform, which it looks like you are doing.

To test this out, if you can move to a 32 bit platform and from there you
can use sos to see a more accurate disassembly.

To prepare your environment you need to enable unmanaged debugging for the
project. You do this in the project properties form on the Debug tab, you
will see an option 'Enable unmanaged code debugging' check that option.

The run the code to you breakpoint, when the debugger hits the breakpoint
you can switch to the 'Immediate Window' and type the following

..load sos

Once sos is loaded you will need to look at the EIP register and use that
address to disassemble the the code. For example the EIP might be 008308D2,
so again in the 'Immediate Window' you can type the following

!u 008308D2

You will see a similar disassembly to what VS was giving, with a few extra
nuggets of info and more importantly in your case the correct addresses,
which are calls to the stubs which ensure the code is JITted. Excuse the
oversimplification :)

I am not 100% certain, but I do not believe sos can be used in the 64 bit
environment, but I might be wrong.

Hope this helps
 
Hi John,

The short and sweet is that the Visual Studio debugger is not showing you
the correct values. Too be honest I have not done any of this on a 64 bit
platform, which it looks like you are doing.

To test this out, if you can move to a 32 bit platform and from there you
can use sos to see a more accurate disassembly.

To prepare your environment you need to enable unmanaged debugging for the
project. You do this in the project properties form on the Debug tab, you
will see an option 'Enable unmanaged code debugging' check that option.

The run the code to you breakpoint, when the debugger hits the breakpoint
you can switch to the 'Immediate Window' and type the following

..load sos

Once sos is loaded you will need to look at the EIP register and use that
address to disassemble the the code. For example the EIP might be 008308D2,
so again in the 'Immediate Window' you can type the following

!u 008308D2

You will see a similar disassembly to what VS was giving, with a few extra
nuggets of info and more importantly in your case the correct addresses,
which are calls to the stubs which ensure the code is JITted. Excuse the
oversimplification :)

I am not 100% certain, but I do not believe sos can be used in the 64 bit
environment, but I might be wrong.

Hope this helps
 
Back
Top