This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC,v2] Yank out target_ops->to_sections


Pedro Alves wrote:
> On Sunday 24 May 2009 02:35:20, Pedro Alves wrote:
> 
> > - Again, I've moved the whole handling of unmmaped overlay
> >   sections to memory_xfer_partial.  There used to be a bit of it in xfer_memory.
> >   It's now centralized, and, the memory reads are now always
> >   really dispatched to read directly from files --- previously, they could
> >   go to the core layer first (don't know if there's any target that
> >   mixes core debugging with overlays, but if there is, I believe
> >   this change is correct).
> 
> It seems I don't have access to any target using an overlay manager.  I
> think Cell uses overlays?  Ulrich, perhaps I could ask you the favour of
> confirming that I'm not breaking anything overlay related?  A genaral peek
> over the patch would be much appreciated as well, of course.

Your changes to overlay support look good to me, and I've verified that the
patch introduces no regressions on spu-elf, including the overlay test cases.

In general, I like the idea of your patch, in particular the elimination of
sections from target_ops, and removal of xfer_memory.

I'm not quite sure what to think of the new current_target_sections variable,
in particular its interaction with target_get_section_table.  Why do you need
a generic fallback to current_target_sections, instead of e.g. having exec_ops
implement a to_get_section_table method?  How to you see this work in a
multi-inferior / multi-address-space setup?

Also, I'm not completely sure I understand the implications of the solib_add
change.  The old method allowed callers to explicitly ask that the library
sections be *not* added to the section table, and several callers did that.
With your patch, sections are always added.  Was it always an error to not
add sections?  I'm not really sure why this feature was introduced ...

(Maybe as a follow-on, ...)  Now that we have a struct target_section_table,
some of the interfaces that use two target_section pointers should be changed
to take a single target_section_table pointer, perhaps?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]