Re: Address spaces

[Stan Shebs <stan@codesourcery.com>]

Mark Kettenis wrote:
>> 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.
>   
Struct ptid is handy, but by nature it's tied to running inferiors, 
seems like it would be a little out of place if we needed it to to look 
at execs and symbol files before running.

Stan