This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: 8 bit read
- To: Andrew Cagney <ac131313 at cygnus dot com>, Eli Zaretskii <eliz at is dot elta dot co dot il>
- Subject: Re: 8 bit read
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Thu, 26 Jul 2001 09:18:54 -0700
- Cc: Naushit_Sakarvadia at quintum dot com, gdb at sources dot redhat dot com
- References: <Pine.SUN.3.91.1010726163652.1520C-100000@is>
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