From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Andrew Cagney , Eli Zaretskii Cc: Naushit_Sakarvadia@quintum.com, gdb@sources.redhat.com Subject: Re: 8 bit read Date: Thu, 26 Jul 2001 09:20:00 -0000 Message-id: <1010726161854.ZM24609@ocotillo.lan> References: X-SW-Source: 2001-07/msg00382.html 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