[PATCH 7/7] gdb/debuginfod: Add .debug_line downloading

[Tom Tromey]

>>>>> "Aaron" == Aaron Merey via Gdb-patches <gdb-patches@sourceware.org> writes:

Aaron> This patch adds functions read_formatted_entries_separate and
Aaron> dwarf_decode_line_header_separate.  They are similar to
Aaron> read_formatted_entries and dwarf_decode_line_header except that they are
Aaron> able to work with .debug_line sections originating from separately
Aaron> downloaded files.

I think there has to be some other refactoring to avoid duplicating code
in this patch.  Copying ~300 lines like that seems bad, especially
considering they'll need parallel updates whenever we find bugs, when
DWARF changes, etc.

Aaron> +  gdb::unique_xmalloc_ptr<char> line_path;
Aaron> +  scoped_fd line_fd = debuginfod_section_query (build_id->data,
Aaron> +						build_id->size,
Aaron> +						bfd_get_filename
Aaron> +						  (objfile->obfd.get ()),
Aaron> +						".debug_line",
Aaron> +						&line_path);

For gdb's purposes, it's a shame debuginfod works explicitly on sections
and not as more of a locally-caching filesystem-like API.  With the
latter we would perhaps have very little or nothing to do to make this
work, provided we were careful to keep the gdb-index code lazy about
reading sections.  Also, inside gdb, all the sharing across inferiors
and such would automatically work.  The cost would be whatever BFD
requests when identifying a file, not sure how much data that is.

Anyway, back to current reality -- the DWARF reader already does try to
lazily map section data.  So I think one big question is, why can't this
be the mechanism for all the sections with debuginfod?  That is, stick
the debuginfod calls into dwarf2_section_info::read.  I don't know what
the debuginfod client does under the hood, but if it doesn't cache this
data somewhere, perhaps gdb could.

Tom