From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Per Bothner Cc: gdb@sources.redhat.com Subject: Re: Harvard proposal Date: Mon, 26 Feb 2001 08:34:00 -0000 Message-id: <3A9A8527.87A85677@cygnus.com> References: <200102102025.f1AKPtS11061@rtl.cygnus.com> <3A970CE6.6B2D2F34@cygnus.com> X-SW-Source: 2001-02/msg00365.html Per Bothner wrote: > > Andrew Cagney writes: > > > A CORE_ADDR is a cannonical address within the target address space. A > > CORE_ADDR should, in theory, be able to identify every target byte (or > > if someone gets it working - word). > > To clarify: By "target address space" do you mean the combined address > spaces of all the targets put together, or the address space of any > single target? In other words, should a CORE_ADDR would also provide > some way of identifying a specific sub-space (i.e. specific target)? > Or should sub-space identification (which subsumes process id and host > network address) be something *separate* from the CORE_ADDR? In Chorus an ``actor''s address space; in UNIX, a single processes memory space; on an SMP machine the address space visible to a single CPU. GDB currently doesn't understand the concept of multiple, separate addresses spaces (as would be seen when debugging two separate UNIX processes). > > However, as with traditional C, I'd suggest following the convention of > > CORE_ADDR (void*) for pointers and LONGEST (long) for offsets. > > Again to clarify: We're talking *target* void*, represented as an > integer type in gdb, not a pointer type. A C programmer would be accustomed to code using ``void*'' for a generic address and ``long'' for a generic offset. In a similar way, a GDB developer would be accustomed to using CORE_ADDR when manipulating a generic target address and (in theory) LONGEST when manipulating a generic target offset. Andrew