This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH]: memory region attributes
>>>>> "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