This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC/RFA] gdb extension for Harvard architectures
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: [RFC/RFA] gdb extension for Harvard architectures
- From: Michael Snyder <msnyder at cygnus dot com>
- Date: Tue, 02 Oct 2001 15:09:07 -0700
- CC: Jim Blandy <jimb at cygnus dot com>, gdb-patches at sources dot redhat dot com
- Organization: Red Hat
- References: <3BB4D843.A92818B9@cygnus.com> <3BB512A9.6050801@cygnus.com> <3BB5195F.6050603@cygnus.com> <npu1xhq0d9.fsf@zwingli.cygnus.com> <3BBA2DC9.5060500@cygnus.com>
Andrew Cagney wrote:
>
> > Andrew Cagney <ac131313@cygnus.com> writes:
> >
> >> Would it be better if the cast operator, by default, preserved the
> >> address space of the pointer being cast?
> >
> >
> > That would get a bit hairy. If I've got a value of the type:
> >
> > (@code int * @code * @code * @code)
> >
> > --- that is, "a pointer in code space to a pointer in code space to a
> > pointer in code space to an int in code space" --- and cast it to
> >
> > (int **)
> >
> > (note that I've dropped a layer of pointers here), how far down do we
> > go? Does that become a `@code int * @code * @code'? Or just a `int
> > * @code *'? It's a bit weird.
>
> You don't.
>
> > I kind of think that casts should just work the normal way. People
> > working on machines with separate address spaces have to think a
> > little harder --- I don't think we can really conceal that.
>
> Remember we're talking about poerations that potentially cast a code
> pointer to a data or I/O pointer so this can't be described as normal.
> It is definitly way outside the bounds of the C language spec.
>
> Any way, consider the intent of someone entering a sequence like:
>
> (gdb) x/w foo
> 0x0
> (gdb) x/i foo
> nop
Andrew, right now the "x" command has no knowledge about
separate code and data spaces, so both "x/w foo" and "x/i foo"
will refer to the same address. Whether that address comes
from code or data space depends entirely on the data type of foo.
If foo is a data-like object (eg. an int or an int pointer)
it will come from data space. If foo is a function, it will come
from code space. The purpose of the @code and @data modifiers
is to override this default.
> (gdb) print/x *(int*)foo
> 0xdeadbeef
An (int *) is by default a data pointer.
A function pointer is by default a code pointer.
> vs
> (gdb) print/x *(int*)foo
> 0x0
>
> and where should this go:
>
> (gdb) set *(int*)foo = 0xdeadbeef
This will go to data space. Any "normal" data type will default to data
space (as it already does). The @code and @data modifiers are for when
you want to alter the default behavior.
> This mysterious address switching strikes me as wierd.
You are right -- it's wierd. ;-)