assembly display -vs- popups

assembly display -vs- popups

[Tom Tromey]

While debugging my gcj-generated stubs I always use the assembly view,
because there isn't any source corresponding to the code I'm
debugging.

In assembly mode I see code like this (on my x86 box):

-	0x403077ca	<simple_int.nat(int)+42>:		mov    %eax,0xfffffff8(%ebp)

If I highlight "%ebp", I'd like it to display the value of the
register in the balloon.  Unfortunately, it does not, because "%ebp"
is not valid gdb syntax for getting the register value.

A hack would be to do `s/%/$/' to the expression in assembly mode.

This is bad because ideally I'd like to be able to highlight
0xfffffff8(%ebp) and have it do the right thing.  Maybe assembly needs
a different expression evaluator, making this a more general gdb
problem?

Tom

Re: assembly display -vs- popups

[James Ingham]

Tom,

 > While debugging my gcj-generated stubs I always use the assembly view,
 > because there isn't any source corresponding to the code I'm
 > debugging.
 > 
 > In assembly mode I see code like this (on my x86 box):
 > 
 > -	0x403077ca	<simple_int.nat(int)+42>:		mov    %eax,0xfffffff8(%ebp)
 > 
 > If I highlight "%ebp", I'd like it to display the value of the
 > register in the balloon.  Unfortunately, it does not, because "%ebp"
 > is not valid gdb syntax for getting the register value.
 > 
 > A hack would be to do `s/%/$/' to the expression in assembly mode.

This makes me nervous.  It is not guaranteed to work everywhere.  Not
everybody uses % for registers in their standard dissassembler.  On
MIPS a $ is used.  Who knows what some other architecture might
choose...  More importantly, there is no guarantee that replacing the
% with $ is benign...

 > 
 > This is bad because ideally I'd like to be able to highlight
 > 0xfffffff8(%ebp) and have it do the right thing.  Maybe assembly needs
 > a different expression evaluator, making this a more general gdb
 > problem?

I think this is right; Insight just feeds whatever you highlight to
evaluate_expression...  The problem is that gdb doesn't seem to
evaluate assembly expressions in the format used by the disassembler,
which certainly seems wrong to me.

Jim