Re: [RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder <msnyder at cygnus dot com>]

Andrew Cagney wrote:
> 
> >> Any way, consider the intent of someone entering a sequence like:
> >>
> >> (gdb) x/w foo
> >> 0x0
> >> (gdb) x/i foo
> >> nop
> >> (gdb) print/x *(int*)foo
> >> 0xdeadbeef
> >>
> >> vs
> >> (gdb) print/x *(int*)foo
> >> 0x0
> >>
> >> and where should this go:
> >>
> >> (gdb) set *(int*)foo = 0xdeadbeef
> >>
> >> This mysterious address switching strikes me as wierd.
> >
> >
> > It *is* weird, but I think it's an intrinsic weirdness of Harvard
> > architectures that it would be a disservice to conceal.
> >
> > Seriously, you can't protect the user from the oddities of the chip
> > they're working on.  And I think we shouldn't: GDB's job is to help
> > people observe the behavior of the program, and tools for observation
> > must be careful not to edit reality too much.  It's perfectly okay to
> > tell someone, "You don't understand your architecture; do it this
> > way."  (Rather, the manual should say this, and we should point them
> > at it.)
> 
> We're also expected to make GDB user friendly.
> 
> In the above, if the user wanted to convert the function pointer into a
> data pointer then they would enter:
> 
>         (@data int *)foo
> 
> and who knows what the result would be.

The result would be a data address corresponding to the 
code address 'foo'.  For example, if code addresses have their
32nd bit set and data addresses do not, then the address of foo
might be 0x80001234, and (@data int *) foo would be 0x1234.
BTW, (int *) foo would also be 0x1234, because an int pointer
is by default located in data space.