Re: 8 bit read

[Andrew Cagney <ac131313@cygnus.com>]

>> Is it possible to come up with a single number (address) which
>> represents ($fs:foo)?
> 
> 
> 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.



> 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.  The d10v target managed 
this.  I'd view it as a proof of concept.


>> IMO, it would probably be better to redefine CORE_ADDR to have an
>> explicit segment descriptor and address field.
> 
> 
> Yes, but redefining CORE_ADDR is an adventure I'd like to avoid ;-)


It is still an adventure GDB should take. It is like tiddles (TPID) - it 
is going to hurt :-)


> Btw, is there any provision in GDB to add a constant to each address
> recorded in the debug info, so that CORE_ADDR holds addresses with
> that constant added?  (In the case of DJGPP, that constant is the base
> address of the data segment, and is only known at run time.)


The readers can at least do sign-extension.  The 32 bit MIPS makes use 
of this.


> If this is possible, I could use linear addresses instead of offsets
> from the segment's base, and then CORE_ADDR would be wide enough to
> hold addresses outside the data segment as well (assuming they all
> belong to a single Page Directory).


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

	Andrew