This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


> 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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]