Re: [PATCH]: memory region attributes

[Michael Snyder <msnyder at cygnus dot com>]

"J.T. Conklin" wrote:
> 
> >>>>> "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.

Nope -- it's core code.  Everything pretty much depends on it.

> 
> Is there any reason why rw_common() doesn't call target_xfer_memory()?

Yep.  Infinite recursion.  Target_xfer_memory calls thread_db functions
which call rw_common.  I know, it's very tempting.  I found this out
the hard way.  ;-)

> 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.

See above.

> 
> 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.

Then you have to design the attribute infrastructure so as not to
break existing targets.  ;-(