Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: gdb-patches@sourceware.org, Jan Kratochvil <jan.kratochvil@redhat.com>
Subject: Re: [PATCH] On-demand loading of shlib's debuginfo
Date: Thu, 21 Jul 2011 19:21:00 -0000	[thread overview]
Message-ID: <201107211936.04731.pedro@codesourcery.com> (raw)
In-Reply-To: <m362mvfqlh.fsf@redhat.com>

On Thursday 21 July 2011 19:14:50, Sergio Durigan Junior wrote:
> Pedro Alves <pedro@codesourcery.com> writes:
> 
> > On Wednesday 20 July 2011 21:53:14, Jan Kratochvil wrote:
> >> On Tue, 19 Jul 2011 00:23:49 +0200, Sergio Durigan Junior wrote:
> >> > With that in mind, we decided to tackle this problem progressively, and the
> >> > first part of the solution is ready for submission.
> >> 
> >> That is currently it still touches the solib files on disk for the purpose of
> >> solib_map_sections so that will be a different patch, looking forward.
> >
> > I had skimmed the patch only, and reserved commenting until I had
> > a chance of reading the patch carefuly and figuring it out
> > myself, but since you raise this...
> >
> > Is that the reason then that svr4_match_pc_solist goes through
> > the link map to map a PC to a so_list, instead of having a
> > generic implementation that matches the PC to the so_list's
> > loaded (bfd) sections (that is, just call solib_contains_address_p) ?
> > If so, it'd make more sense IMO to remove that from this patch,
> > and add it only along with a change that lazies mapping in the bfd
> > and its sections as well.  I'm not sure how safe that will be.
> 
> Thanks for the comments, both of you.  After some chat with Jan, I have
> decided that I will work on the second part of this task, i.e., take
> care of solib_map_sections inside update_solib_list, and will only
> submit a new patch when it's done.

Oh, well:-)  I thought the separation was good, as:

 - target sections are used for "set trust-readonly-sections on"
   and similar fallbacks to reading memory from the exec, which
   requires separate dso lazy load points (disassembly? printing
   some address?).

 - its not clear to me the pc -> dso mapping from the link map is
   faster than from the bfd in all scenarios.  E.g., on remote
   targets, it may be faster to get at the bfd info on the host, than
   to remote read memory from the target.

 - I was curious on how much lazing debug info alone was helping,
   vs lazing the bfd reads.

-- 
Pedro Alves


  reply	other threads:[~2011-07-21 18:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-19  5:34 Sergio Durigan Junior
2011-07-20 22:01 ` Jan Kratochvil
2011-07-21 11:13   ` Pedro Alves
2011-07-21 14:03     ` Jan Kratochvil
2011-07-21 15:19       ` Pedro Alves
2011-07-21 20:38         ` Tom Tromey
2011-07-21 18:43     ` Sergio Durigan Junior
2011-07-21 19:21       ` Pedro Alves [this message]
2011-07-21 20:10         ` Jan Kratochvil

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=201107211936.04731.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=sergiodj@redhat.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