Re: [PATCH] On-demand loading of shlib's debuginfo

Pedro Alves
2011-07-21T18:36:25Z

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