Re: [PATCH]: memory region attributes

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Michael" == Michael Snyder <msnyder@cygnus.com> writes:
>> I'd appreciate help from anyone who understands GDB's thread
>> infrastructure.

Michael> Or in this case, solaris's thread infrastructure.  Those
Michael> functions are callbacks exported by GDB to the system library
Michael> libthread_db.  GDB asks that library for information about
Michael> user threads, and that library uses those callback functions
Michael> to read memory from the inferior.

Ok.  I was hoping that it was just dead code that we could slash and 
burn.

Is there any reason why rw_common() doesn't call target_xfer_memory()?
If I'm reading the code correctly, rw_common replicates a lot of what
is in sol_thread_xfer_memory().  If it called target_xfer_memory() it
would support the dcache and memory attributes without any special 
accomidations and without significant overhead.

Michael> So -- if we really need this memory region attribute (I haven't been
Michael> following the discussion too closely), we can possibly include it in
Michael> the ps_prochandle_t struct.  But I wonder -- do we really need it?
Michael> Are memory region attributes meaningful on native solaris?

It is true that native systems don't get much out of the current set
of attributes, but I don't want to preclude someone adding attributes
that might be useful on native platforms.  As such, I think it's best
to get the attribute infrastructure solid on all platforms up front.

        --jtc

-- 
J.T. Conklin
RedBack Networks