Re: [PATCH]: memory region attributes

[Michael Snyder <msnyder at cygnus dot com>]

"J.T. Conklin" wrote:
> 
> >>>>> "Jeff" == Jeff Holcomb <jeffh@redhat.com> writes:
> >> Since these changes have been on the table for a few months with no
> >> objections, I'm going to use my newfound status to commit them.
> >>
> >> This shouldn't cause any problems or undue overhead when no memory
> >> regions are defined.  In the past, I've run this through the test-
> >> suite with no regressions.
> 
> Jeff> I'm no longer able to build on solaris2.5 after this change.  Looks like
> Jeff> sol-thread.c needs to be updated also?
> 
> Yes.  Sorry about that.
> 
> I just checked in a patch that will allow solaris to build.  In
> rw_common(), I had to pass 0 as the attrib argument because I couldn't
> find out where to get the attribute.  While I could call lookup region
> and break up the operation like is done in target_xfer_memory(), that
> should really be done in an upper layer and passed through.  The thing
> is, I can't find out how rw_common() is called.  It's called by
> ps_p{d,t}{read,write}, but I don't know where those routines are
> called from.
> 
> I'd appreciate help from anyone who understands GDB's thread infrastructure.

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

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