Re: 8 bit read

[Kevin Buettner <kevinb@cygnus.com>]

On Jul 26,  4:45pm, Eli Zaretskii wrote:

> On Thu, 26 Jul 2001, Andrew Cagney wrote:
> 
> > > No, because CORE_ADDR is not wide enough to engulf both.  Making
> > > CORE_ADDR wider is something I'd prefer to avoid, since it will affect
> > > Binutils as well.
> > 
> > What Kevin is suggesting here is, from GDB's point of view, the correct 
> > approach.  A CORE_ADDR is a cannonical address - any pointer expression 
> > is converted to that cannonical value.  On the x86, it could carry an 
> > indication that the offset part belongs to either code, I/O, .. space.
> 
> The problem is, I don't have enough bits in CORE_ADDR to include those 
> indications.

I think if you review the mailing list archives, you'll find that more
than one person has suggested turning CORE_ADDR into a struct.  What
would such a struct look like?  Maybe something like this:

    struct core_addr
      {
        bfd_vma addr;		/* what we have now...  */
	int addr_space;		/* address space selector */
				/* maybe this should be an enum?  */
      };
    typedef struct core_addr CORE_ADDR;

(I'm sure we can think of better names for the members, but you get
the idea.)

I we take such a step, there'll be a fair chunk of code which won't
really notice the difference.  Such code performs no real manipulation
of a CORE_ADDR, it either stashes the value away and/or passes it on
to somewhere else.

The code that's going to be affected is that in which a constant is
added to or subtracted from a CORE_ADDR.  (There's some masking that
goes on too sometimes.)  For these, we'll need a constructor.  I.e,
something like the following...

    CORE_ADDR pc = read_pc ();
    ...
    pc = pc + 4;		/* Advance pc to next instruction.  */
    
might become...

    CORE_ADDR pc = read_pc ();
    ...
    pc = core_addr_add_int (pc, 4);
				/* Advance pc to next instruction.  */

where core_addr_add_int() has the obvious definition...

    CORE_ADDR
    core_addr_add_int (CORE_ADDR addr, int offset)
    {
      CORE_ADDR retval;

      retval.addr_space = addr.addr_space;
      retval.addr = addr.addr + offset;

      return retval;
    }

The nice thing about all of this is that a core_addr_add_core_addr()
could be made to internal_error() when attempting to add incompatible
addresses.  (As it is, our Harvard architecture implementations won't
care if you try to add a data address to a code address.  Doing so
probably represents a programming error though.)

Kevin