public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
To: Aaron Merey <amerey@redhat.com>
Cc: aburgess@redhat.com, gdb-patches@sourceware.org
Subject: Re: [PATCH 4/4 v5] gdb/debuginfod: Add .debug_line downloading
Date: Tue, 26 Dec 2023 21:30:14 -0300	[thread overview]
Message-ID: <875y0kcwrt.fsf@linaro.org> (raw)
In-Reply-To: <20231028002008.1105723-5-amerey@redhat.com>


Aaron Merey <amerey@redhat.com> writes:

> -/* Read directory or file name entry format, starting with byte of
> -   format count entries, ULEB128 pairs of entry formats, ULEB128 of
> -   entries count and the entries themselves in the described entry
> -   format.  */
> +
> +/* Like read_formatted_entries but the .debug_line and .debug_line_str

This function is also called read_formatted_entries, so the comment is a
bit confusing to me. Perhaps start with "Like the other
read_formatted_entries, but ..."?

> +   are stored in LINE_BUFP and LINE_STR_DATA.  This is used for cases
> +   where these sections are read from separate files without necessarily
> +   having access to the entire debuginfo file they originate from.  */
>  
>  static void
> -read_formatted_entries (dwarf2_per_objfile *per_objfile, bfd *abfd,
> -			const gdb_byte **bufp, struct line_header *lh,
> -			unsigned int offset_size,
> -			void (*callback) (struct line_header *lh,
> -					  const char *name,
> -					  dir_index d_index,
> -					  unsigned int mod_time,
> -					  unsigned int length))
> +read_formatted_entries
> +  (bfd *parent_bfd, const gdb_byte **line_bufp,
> +   const gdb::array_view<const gdb_byte> line_str_data,
> +   struct line_header *lh,
> +   unsigned int offset_size,
> +   void (*callback) (struct line_header *lh,
> +		     const char *name,
> +		     dir_index d_index,
> +		     unsigned int mod_time,
> +		     unsigned int length))
>  {

<snip>

> @@ -166,36 +173,48 @@ read_formatted_entries (dwarf2_per_objfile *per_objfile, bfd *abfd,
>  	  switch (form)
>  	    {
>  	    case DW_FORM_string:
> -	      string.emplace (read_direct_string (abfd, buf, &bytes_read));
> +	      string.emplace (read_direct_string (parent_bfd, buf, &bytes_read));
>  	      buf += bytes_read;
>  	      break;
>  
>  	    case DW_FORM_line_strp:
>  	      {
> -		const char *str
> -		  = per_objfile->read_line_string (buf, offset_size);
> +		if (line_str_data.empty ())
> +		  error (_("Dwarf Error: DW_FORM_line_strp used without " \
> +			   "required section"));

Is error the correct response here? Or should the bad form just be
complained about and ignored?

> +		if (line_str_data.size () <= offset_size)

I don't understand this check. Shouldn't it be the following?

  if (line_str_data.size () <= str_offset)

> +		  error (_("Dwarf Error: DW_FORM_line_strp pointing outside " \
> +			   "of section .debug_line"));

IIUC, the message should say ".debug_line_str" instead of ".debug_line".
Also, same question about error vs complaint.

> +
> +		ULONGEST str_offset = read_offset (parent_bfd, buf, offset_size);
> +
> +		const char *str;
> +		if (str_buf[str_offset] == '\0')
> +		  str = nullptr;
> +		else
> +		  str = (const char *) (str_buf + str_offset);
>  		string.emplace (str);
>  		buf += offset_size;
> +		break;
>  	      }
> -	      break;

<snip>

> +gdb::array_view<const gdb_byte>
> +mapped_debug_line::read_debug_line_separate
> +  (char *filename, std::unique_ptr<index_cache_resource> *resource)

filename can be const char *.

> +{
> +  if (filename == nullptr)
> +    return {};
> +
> +  try
> +  {
> +    line_resource_mmap *mmap_resource
> +      = new line_resource_mmap (filename);
> +
> +    resource->reset (mmap_resource);
> +
> +    return gdb::array_view<const gdb_byte>
> +      ((const gdb_byte *) mmap_resource->mapping.get (),
> +       mmap_resource->mapping.size ());
> +  }
> +  catch (const gdb_exception &except)
> +  {
> +    exception_print (gdb_stderr, except);
> +  }
> +
> +  return {};
> +}
> +
> +/* See read.h.  */
> +
> +bool
> +mapped_debug_line::read_debug_line_from_debuginfod (objfile *objfile)
> +{
> +  const bfd_build_id *build_id = build_id_bfd_get (objfile->obfd.get ());
> +  if (build_id == nullptr)
> +    return false;
> +
> +  gdb::unique_xmalloc_ptr<char> line_path;
> +  scoped_fd line_fd = debuginfod_section_query (build_id->data,
> +						build_id->size,
> +						bfd_get_filename
> +						  (objfile->obfd.get ()),
> +						".debug_line",
> +						&line_path);
> +
> +  if (line_fd.get () < 0)
> +    return false;
> +
> +  gdb::unique_xmalloc_ptr<char> line_str_path;
> +  scoped_fd line_str_fd = debuginfod_section_query (build_id->data,
> +						    build_id->size,
> +						    bfd_get_filename
> +						      (objfile->obfd.get ()),
> +						    ".debug_line_str",
> +						    &line_str_path);
> +
> +  line_data = read_debug_line_separate (line_path.get (), &line_resource);
> +  line_str_data = read_debug_line_separate (line_str_path.get (),
> +					    &line_str_resource);
> +
> +  const gdb_byte *line_ptr = line_data.data ();
> +
> +  while (line_ptr < line_data.data () + line_data.size ())
> +    {
> +      line_header_up lh
> +	= dwarf_decode_line_header (objfile->obfd.get (),
> +				    line_data, line_str_data,
> +				    &line_ptr, false,
> +				    nullptr, nullptr);
> +      line_headers.emplace_back (lh.release ());

This line is destroying a line_header_up just to construct a new one to
put in the vector. I believe you can use std::move here instead to avoid
the extra work.

> +    }
> +
> +  return true;
> +}
> +#endif /* !HAVE_SYS_MMAN_H */

-- 
Thiago

      parent reply	other threads:[~2023-12-27  0:30 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-28  0:20 [PATCH 0/4] On-demand debuginfo downloading Aaron Merey
2023-10-28  0:20 ` [PATCH 1/4 v7] gdb: Buffer output streams during events that might download debuginfo Aaron Merey
2023-11-12 20:20   ` Aaron Merey
2023-11-20 18:38     ` [PING*2][PATCH " Aaron Merey
2023-11-30 16:29       ` [PING*3][PATCH " Aaron Merey
2023-12-12 15:00         ` [PING*4][PATCH " Aaron Merey
2023-12-20 14:57           ` [PING*5][PATCH " Aaron Merey
2023-12-26 16:28   ` [PATCH " Thiago Jung Bauermann
2024-01-17 17:49     ` Aaron Merey
2024-01-17 18:05   ` Andrew Burgess
2023-10-28  0:20 ` [PATCH 2/4 v2] gdb/progspace: Add reverse safe iterator and template for unwrapping iterator Aaron Merey
2023-11-12 20:20   ` Aaron Merey
2023-11-20 18:39     ` [PING*2][PATCH " Aaron Merey
2023-11-30 16:30       ` [PING*3][PATCH " Aaron Merey
2023-12-12 15:01         ` [PING*4][PATCH " Aaron Merey
2023-12-20 14:57           ` [PING*5][PATCH " Aaron Merey
2023-12-26 17:09   ` [PATCH " Thiago Jung Bauermann
2023-10-28  0:20 ` [PATCH 3/4 v4] gdb/debuginfod: Support on-demand debuginfo downloading Aaron Merey
2023-11-12 20:20   ` Aaron Merey
2023-11-20 18:39     ` [PING*2][PATCH " Aaron Merey
2023-11-30 16:30       ` [PING*3][PATCH " Aaron Merey
2023-12-12 15:01         ` [PING*4][PATCH " Aaron Merey
2023-12-20 14:57           ` [PING*5][PATCH " Aaron Merey
2023-12-26 18:35   ` [PATCH " Thiago Jung Bauermann
2023-10-28  0:20 ` [PATCH 4/4 v5] gdb/debuginfod: Add .debug_line downloading Aaron Merey
2023-11-12 20:21   ` Aaron Merey
2023-11-20 18:40     ` [PING*2][PATCH " Aaron Merey
2023-11-30 16:30       ` [PING*3][PATCH " Aaron Merey
2023-12-12 15:08         ` [PING*4][PATCH " Aaron Merey
2023-12-20 14:58           ` [PING*5][PATCH " Aaron Merey
2023-12-27  0:30   ` Thiago Jung Bauermann [this message]

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=875y0kcwrt.fsf@linaro.org \
    --to=thiago.bauermann@linaro.org \
    --cc=aburgess@redhat.com \
    --cc=amerey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).