Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: pedro@codesourcery.com (Pedro Alves)
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC,v2] Yank out target_ops->to_sections
Date: Wed, 27 May 2009 18:24:00 -0000	[thread overview]
Message-ID: <200905271824.n4RIO6m6010275@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <200905270030.12112.pedro@codesourcery.com> from "Pedro Alves" at May 27, 2009 12:30:11 AM

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


  parent reply	other threads:[~2009-05-27 18:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-24  1:35 Pedro Alves
2009-05-26 23:30 ` Pedro Alves
2009-05-27  1:30   ` Doug Evans
2009-05-27 18:24   ` Ulrich Weigand [this message]
2009-05-29 14:13     ` Pedro Alves
2009-05-30 16:39       ` [RFC,v3] " Pedro Alves
2009-06-02 11:10         ` Ulrich Weigand
2009-06-03 18:57           ` Pedro Alves
2009-06-02 11:06       ` [RFC,v2] " Ulrich Weigand
2009-06-03 16:26         ` Pedro Alves
2009-06-03 19:36           ` Ulrich Weigand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200905271824.n4RIO6m6010275@d12av02.megacenter.de.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox