Disassembly notation in 7.1 - can't see variable's address

R

Rudy Ray Moore

This c++ line in MSVC++ .net 2003 7.1:
f(&d);
Generates this assembly:
00411C67 lea eax,[d]
00411C6A push eax
00411C6B call f (411159h)
00411C70 add esp,4

What's up with the "[d]"? I want to see the pointer value! How do I make
the pointer value appear? Please don't say "open your executable in
notepad."

Rudy

PS: I'm trying to debug a problem where the pointer value (&d) changes
during execution!
 
J

Joe Delekto

Greets,

Probably the best way to do this in the debugger is to add "&d" to your
watch window. Either that, or you can open up the "Register" window in the
debugger and watch the effective address which is loaded into the EAX
register.

Regards,

Joe
 
R

Rudy Ray Moore

Hi Joe,

Thanks for the suggestion.

I've been using the "watch window" suggestion, but I have noticed that in
the watch window, "&d" changes from line to line! In order to track down
this problem, I would like to know how the watch window knows to calculate
&d.

I assume the watch window did this by looking at assembly.

When I look at assembly, I don't see the addresses of my local variables.
All I see is the name of the local variable in sqare brackets:
00411C67 lea eax,[d]

The watch window must not be using the "assembly text" to determine the
value of "&d". I wonder how it does this. :-/

Thanks,

Rudy


Joe Delekto said:
Greets,

Probably the best way to do this in the debugger is to add "&d" to your
watch window. Either that, or you can open up the "Register" window in the
debugger and watch the effective address which is loaded into the EAX
register.

Regards,

Joe

Rudy Ray Moore said:
This c++ line in MSVC++ .net 2003 7.1:
f(&d);
Generates this assembly:
00411C67 lea eax,[d]
00411C6A push eax
00411C6B call f (411159h)
00411C70 add esp,4

What's up with the "[d]"? I want to see the pointer value! How do I make
the pointer value appear? Please don't say "open your executable in
notepad."

Rudy

PS: I'm trying to debug a problem where the pointer value (&d) changes
during execution!
 
J

Joe Delekto

Greets,

Well, keep in mind that your variable is on the stack and that it's going
to be relative to some location on the stack. If your function is
re-entrant, it is quite possible that you will see this value change between
calls. (Depending upon where the location of the variable is relative to
the current base pointer.) If you examine the value of the EAX register
after the "lea, [d]" instruction, you should see the same value as shown by
&d in the watch window. I'm not sure how you're seeing it change line by
line --is this a managed C++ application?

Regards,

Joe

Rudy Ray Moore said:
Hi Joe,

Thanks for the suggestion.

I've been using the "watch window" suggestion, but I have noticed that in
the watch window, "&d" changes from line to line! In order to track down
this problem, I would like to know how the watch window knows to calculate
&d.

I assume the watch window did this by looking at assembly.

When I look at assembly, I don't see the addresses of my local variables.
All I see is the name of the local variable in sqare brackets:
00411C67 lea eax,[d]

The watch window must not be using the "assembly text" to determine the
value of "&d". I wonder how it does this. :-/

Thanks,

Rudy


Joe Delekto said:
Greets,

Probably the best way to do this in the debugger is to add "&d" to your
watch window. Either that, or you can open up the "Register" window in the
debugger and watch the effective address which is loaded into the EAX
register.

Regards,

Joe

Rudy Ray Moore said:
This c++ line in MSVC++ .net 2003 7.1:
f(&d);
Generates this assembly:
00411C67 lea eax,[d]
00411C6A push eax
00411C6B call f (411159h)
00411C70 add esp,4

What's up with the "[d]"? I want to see the pointer value! How do I make
the pointer value appear? Please don't say "open your executable in
notepad."

Rudy

PS: I'm trying to debug a problem where the pointer value (&d) changes
during execution!
 
R

Rudy Ray Moore

Hi Joe,

It's not managed c++. Carl Daniel suggests the value is changing "line by
line" because one of my function calls is hosing up the stack pointer (esp),
and consequently altering the address of each of my local variables.

Chris

Joe Delekto said:
Greets,

Well, keep in mind that your variable is on the stack and that it's going
to be relative to some location on the stack. If your function is
re-entrant, it is quite possible that you will see this value change between
calls. (Depending upon where the location of the variable is relative to
the current base pointer.) If you examine the value of the EAX register
after the "lea, [d]" instruction, you should see the same value as shown by
&d in the watch window. I'm not sure how you're seeing it change line by
line --is this a managed C++ application?

Regards,

Joe

Rudy Ray Moore said:
Hi Joe,

Thanks for the suggestion.

I've been using the "watch window" suggestion, but I have noticed that in
the watch window, "&d" changes from line to line! In order to track down
this problem, I would like to know how the watch window knows to calculate
&d.

I assume the watch window did this by looking at assembly.

When I look at assembly, I don't see the addresses of my local variables.
All I see is the name of the local variable in sqare brackets:
00411C67 lea eax,[d]

The watch window must not be using the "assembly text" to determine the
value of "&d". I wonder how it does this. :-/

Thanks,

Rudy


Joe Delekto said:
Greets,

Probably the best way to do this in the debugger is to add "&d" to your
watch window. Either that, or you can open up the "Register" window
in
the
debugger and watch the effective address which is loaded into the EAX
register.

Regards,

Joe

This c++ line in MSVC++ .net 2003 7.1:
f(&d);
Generates this assembly:
00411C67 lea eax,[d]
00411C6A push eax
00411C6B call f (411159h)
00411C70 add esp,4

What's up with the "[d]"? I want to see the pointer value! How do
I
make
the pointer value appear? Please don't say "open your executable in
notepad."

Rudy

PS: I'm trying to debug a problem where the pointer value (&d) changes
during execution!
 
S

Sven Carstensen

Hi Rudy,

Rudy Ray Moore said:
Hi Joe,

Thanks for the suggestion.

I've been using the "watch window" suggestion, but I have noticed that in
the watch window, "&d" changes from line to line! In order to track down
this problem, I would like to know how the watch window knows to calculate
&d.

Can you show as the code where the address of d is changing from line to
line when watched in the debugger. This is truely not the expected
behaviour.
 
R

Rudy Ray Moore

Sven Carstensen said:
Can you show as the code where the address of d is changing from line to
line when watched in the debugger. This is truely not the expected
behaviour.

Hi Sven,

Unfortunately, I cannot because the application is too large to post.

Carl Daniel suggests that the problem might be that my code calls a function
which messes up the stack pointer.

Since all local variables are addressed relative to the stack pointer, once
the stack pointer gets hosed, the local variables will be hosed too. I'll
post more info when I get it, but thanks for your help.

Rudy
 
S

Sven Carstensen

Hi Rudy,

Rudy Ray Moore said:
Hi Sven,

Unfortunately, I cannot because the application is too large to post.

Carl Daniel suggests that the problem might be that my code calls a function
which messes up the stack pointer.

OK, so its not that the address of your local variable changes from line to
line but only if one line contains a function call which might mess up the
stack, yes? Like so:

void foo()
{
int d = 0;
// look at &d
d = d + 42;
// look at &d which is still unchanged
doSomethingEvil();
// look at &d which is now different than before the function call
}

If that is the case you seem to have a good point to narrow down the problem
and find the evil function.

Bye,
SvenC
 
R

Rudy Ray Moore

Sven Carstensen said:
void foo()
{
int d = 0;
// look at &d
d = d + 42;
// look at &d which is still unchanged
doSomethingEvil();
// look at &d which is now different than before the function call
}

That describes my problem precisely!
 
Top