address space support

address space support

[Doug Evans]

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.

Re: address space support

[Daniel Jacobowitz]

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

Re: address space support

[Michael Snyder]

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?   ;-)

Re: address space support

[Eli Zaretskii]

> From: Michael Snyder <msnyder@specifix.com>
> Cc: Doug Evans <dje@sebabeach.org>, gdb@sourceware.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.

Re: address space support

[Ulrich Weigand]

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.Weigand@de.ibm.com