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]

[Jim Blandy <jimb@cygnus.com>] RFA: fix GDB casts when pointers are not addresses



Hi, David.  I think this one is in your area, too.  There are more
examples and explanations in this thread on gdb-patches.

------- Start of forwarded message -------
From: Jim Blandy <jimb@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: RFA: fix GDB casts when pointers are not addresses
Message-Id: <20010628225704.9AB635E9CB@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.

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.

Index: gdb/valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.36
diff -c -r1.36 valops.c
*** gdb/valops.c	2001/05/19 15:20:14	1.36
--- gdb/valops.c	2001/06/28 22:40:05
***************
*** 281,287 ****
  	      break;		/* fall out and go to normal handling */
  	    }
  	}
!       longest = value_as_long (arg2);
        return value_from_longest (type, convert_to_boolean ?
  				 (LONGEST) (longest ? 1 : 0) : longest);
      }
--- 281,298 ----
  	      break;		/* fall out and go to normal handling */
  	    }
  	}
! 
!       /* When we cast pointers to integers, we mustn't use
!          POINTER_TO_ADDRESS to find the address the pointer
!          represents, as value_as_long would.  GDB should evaluate
!          expressions just as the compiler would --- and the compiler
!          sees a cast as a simple reinterpretation of the pointer's
!          bits.  */
!       if (code2 == TYPE_CODE_PTR)
!         longest = extract_unsigned_integer (VALUE_CONTENTS (arg2),
!                                             TYPE_LENGTH (type2));
!       else
!         longest = value_as_long (arg2);
        return value_from_longest (type, convert_to_boolean ?
  				 (LONGEST) (longest ? 1 : 0) : longest);
      }

------- End of forwarded message -------


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