Re: RFA: fix GDB casts when pointers are not addresses

[David Taylor <taylor at candd dot org>]

    From: Jim Blandy <jimb@zwingli.cygnus.com>
    Date: Thu, 28 Jun 2001 17:57:04 -0500 (EST)

    This patch changes GDB to match GCC's behavior when casting pointers
    to integers on machines where pointers are not direct byte addresses
    (like Harvard architectures).

    This patch is a prerequisite for removing the D10V-specific code from
    the GDB core (for example, see value_at in valops.c).

    The details:

    In the scope of a declaration like this:

	    void (*f) ();

    the C standards say expressions like these yield unspecified values:

	    (int) f;

    In the absence of clear direction from an independent standard, I feel
    that GDB should match GCC's behavior.

    On most processors, there's a single obvious behavior for a cast from
    a pointer to an integer of the same size.  However, the D10V has a
    256k code address space, indexed by 16-bit pointers; all instructions
    are 32-bit values, naturally aligned, so we multiply a 16-bit code
    pointer's value by four to get the corresponding byte address in code
    space.  This means that there are two plausible interpretations for a
    cast from code ptr to integer:

    - the integer produced is the byte address in the code segment (so for
      the D10V, this would be the pointer's value times four), or

    - the integer produced is the 16-bit pointer value reinterpreted as a
      16-bit integer --- no adjustment takes place.

    Currently, GDB implements the former, while GCC implements the former.
    This patch changes GDB to match GCC.

former, former; one should be latter...

    One could argue that `value_as_long' should not convert pointers to
    addresses, but there are many other places in GDB that assume it will.

    2001-06-28  Jim Blandy  <jimb@redhat.com>

	    * valops.c (value_cast): When casting a pointer to an integer,
	    don't convert it to an address.

I approve of bringing the compiler and debugger into agreement on how
to interpret an expression.  You might want to make note of that in
the ChangeLog entry.

Approved.