Re: 8 bit read

[Eli Zaretskii <eliz@is.elta.co.il>]

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.

> > It means to use a non-default segment selector to read and write
> > memory.
> 
> That really means do a virtual->real address translation on all 
> addresses as they head towards the target.

No, it means converting an offset relative to segment's base to a linear
address.  I don't need to map to a physical address in this case, that's 
something that is done transparently by the CPU, given the page tables 
that are set by the OS.

> The d10v target managed this.  I'd view it as a proof of concept.

If that was done by encoding all the info into CORE_ADDR, I cannot take 
this path, because CORE_ADDR is 32 bits and addresses are also 32 bits.

> If I understand what you're saying correctly, you'd need a virtual 
> (segment:offset) to physical translation somewhere down in the target code.

No, my problem is not a translation--that can be handled by the target 
code.  The problem is how to pass that information to the target code, 
given that it can only be either in the address itself or in the memory 
attributes which go with that address.