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: Jim Blandy <jimb at cygnus dot com>
- Subject: Re: [RFC/RFA] gdb extension for Harvard architectures
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Tue, 02 Oct 2001 17:12:41 -0400
- Cc: Michael Snyder <msnyder at cygnus dot com>,gdb-patches at sources dot redhat dot com
- References: <3BB4D843.A92818B9@cygnus.com> <3BB512A9.6050801@cygnus.com> <3BB5195F.6050603@cygnus.com> <npu1xhq0d9.fsf@zwingli.cygnus.com>
> 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
(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.
Andrew