RFA: fix GDB casts when pointers are not addresses

David Taylor taylor@candd.org
Mon Jul 9 19:55:00 GMT 2001


    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.



More information about the Gdb-patches mailing list