This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Address spaces


> Date: Fri, 25 Jul 2008 11:22:11 -0700
> From: Stan Shebs <stanshebs@earthlink.net>
> 
> Michael Snyder wrote:
> > Anyway, the idea of making CORE_ADDR a struct has been 
> > around for a long time.  We've done our best to avoid it, 
> > but sort of always known it would come back one day.
> >   
> Where my prototyping is evolving is to have a new type of object that is 
> the struct, tentatively called "target address", consisting of address 
> space + CORE_ADDR. From poking through all the references to CORE_ADDR, 
> it looks to me like 90%+ have an implicit single address space, so 
> structifying seems like an unnecessary nuisance. For instance, when 
> you're doing prologue analysis you're only going to be working in the 
> one address space (at least for non-Harvard). So I'm thinking higher 
> levels will pass around target addresses in a mostly-opaque way, then 
> when one gets down to working on a specific program / address space, the 
> CORE_ADDRs are extracted and used much as they are now.
> 
> While not as abstractly elegant as making all addresses into objects 
> right off, it doesn't preclude us from going in that direction; someone 
> who wants to make a subsystem use target addresses instead of CORE_ADDRs 
> throughout could do so.

Did you consider extending 'struct ptid' with an adress space
identifier?  In a way, POSIX processes already correspond to an
address space, and the ptid is likely to be available in many places
where you need to make the distinction.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]