This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: address space support
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: dje at sebabeach dot org (Doug Evans)
- Cc: gdb at sourceware dot org
- Date: Mon, 21 Apr 2008 14:57:32 +0200 (CEST)
- Subject: Re: address space support
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