address space support

At Transmeta we had a hack to implement address spaces.  
I.e., 
CORE_ADDR isn't enough to fully describe all the bits of
"memory" one 
might want to examine.  One could do things like "x/x 
<addr-space-name>:<address>".   Using that
we also hacked in support for 
x86 segments, so one could do "x/x fs:1234".

We didn't want to maintain a ton of local mods so we took a
minimalist 
route.  Other ways that have been discussed in the past are
things like 
turning CORE_ADDR into a struct:

typedef struct { int address_space ; OLD_CORE_ADDR address;
} NEW_CORE_ADDR;

or some such (appropriately typed, named, etc.).

But that's a ton of work, and not necessarily a maintainable
way to go 
(the common case is addresses are just ints).  Hacking
CORE_ADDR by 
putting the address space in the upper bits doesn't
necessarily work either.

So I don't have a specific proposal, I'm just taking a
survey of where 
things have left off.

On Sat, Apr 19, 2008 at 09:38:26AM -0700, Doug Evans wrote:
> But that's a ton of work, and not necessarily a
maintainable way to go  
> (the common case is addresses are just ints).  Hacking
CORE_ADDR by  
> putting the address space in the upper bits doesn't
necessarily work 
> either.

May not necessarily work but that's the state of the art. 
All the
targets with address spaces in GDB today have relatively
small
addressable areas so there are some bits to use.  And we use
the same
convention for CORE_ADDR that GNU binutils uses in the ELF
symbol
table, generally.

Also see "code" and "data", though there's nothing in the manual
about them... TYPE_FLAG_CODE_SPACE and
TYPE_FLAG_DATA_SPACE.

-- 
Daniel Jacobowitz
CodeSourcery

Doug Evans wrote:

> At Transmeta we had a hack to implement address spaces.
  I.e., 
> CORE_ADDR isn't enough to fully describe all the bits
of "memory" one 
> might want to examine.  One could do things like
"x/x 
> <addr-space-name>:<address>".   Using
that we also hacked in support for 
> x86 segments, so one could do "x/x fs:1234".
> 
> We didn't want to maintain a ton of local mods so we
took a minimalist 
> route.  Other ways that have been discussed in the past
are things like 
> turning CORE_ADDR into a struct:
> 
> typedef struct { int address_space ; OLD_CORE_ADDR
address; } NEW_CORE_ADDR;
> 
> or some such (appropriately typed, named, etc.).
> 
> But that's a ton of work, and not necessarily a
maintainable way to go 
> (the common case is addresses are just ints).  Hacking
CORE_ADDR by 
> putting the address space in the upper bits doesn't
necessarily work either.

My current out-of-tree patch to support combined PPU/SPU
debugging 
on the Cell/B.E. does use the latter method (encode address
space into
the upper bits of CORE_ADDR).  I'd certainly prefer to see a
more
generic method supported by core GDB as well ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigandde.ibm.com

On Sun, 2008-04-20 at 10:32 -0400, Daniel Jacobowitz wrote:
> On Sat, Apr 19, 2008 at 09:38:26AM -0700, Doug Evans
wrote:
> > But that's a ton of work, and not necessarily a
maintainable way to go  
> > (the common case is addresses are just ints). 
Hacking CORE_ADDR by  
> > putting the address space in the upper bits
doesn't necessarily work 
> > either.
> 
> May not necessarily work but that's the state of the
art.  All the
> targets with address spaces in GDB today have
relatively small
> addressable areas so there are some bits to use.  And
we use the same
> convention for CORE_ADDR that GNU binutils uses in the
ELF symbol
> table, generally.
> 
> Also see "code" and "data", though there's nothing in the manual
> about them... TYPE_FLAG_CODE_SPACE and
TYPE_FLAG_DATA_SPACE.

Erm, yeah -- those were something I did in 2001, when I was
at Red Hat.  See ChangeLog-2001.

I'd vaguely hoped that the work might be extensible to 
include general address spaces...

Sorry about the missing docs -- Eli, why didn't you 
catch me on that one?   

> From: Michael Snyder <msnyderspecifix.com>
> Cc: Doug Evans <djesebabeach.org>, gdbsourceware.org
> Date: Mon, 21 Apr 2008 10:57:15 -0700
> 
> Sorry about the missing docs -- Eli, why didn't you 
> catch me on that one?   

Sorry, I don't always have time to read every message in all
the
detail.