public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Will Hawkins <hawkinsw@obs.cr>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v5] gdb: Support embedded source in DWARF
Date: Fri, 19 Apr 2024 14:17:00 -0600	[thread overview]
Message-ID: <87ttjxt8eb.fsf@tromey.com> (raw)
In-Reply-To: <20240412185525.171292-1-hawkinsw@obs.cr> (Will Hawkins's message of "Fri, 12 Apr 2024 14:55:23 -0400")

>>>>> "Will" == Will Hawkins <hawkinsw@obs.cr> writes:

Will> While DW_LNCT_source is not yet finalized in the DWARF standard
Will> (https://dwarfstd.org/issues/180201.1.html), LLVM does emit it.

Will> This patch adds support for it in gdb.

Thanks.

Will> -      m_fullname = find_source_or_rewrite (get_name (), get_comp_dir ());
Will> +      {
Will> +	if (m_is_embedded)
Will> +	  m_fullname = make_unique_xstrdup (embedded_fullname (
Will> +							       get_name (),
Will> +							       get_comp_dir ()));

No line break before the get_name call.

Will> +	  else if (entry.source != nullptr)
Will> +	    {
Will> +	      /* We have an embedded source for the CU.  */
Will> +	      gdb_assert (offset == 1);
Will> +	      cu_file_embedded = true;

This assert makes me a bit nervous.  Can this be fooled by bad input
data?  Or is it really testing some internal invariant?  I couldn't
convince myself it was the latter.

Will> +	fullname.reset (embedded_fullname (dirname, qfn->file_names[index]));

fullname = ...

Will> +  /* Because the line header may tell us information about the CU
Will> +     filename (e.g., whether it is embedded) which will affect other
Will> +     calculations, we have to read that information here.  */
Will> +  line_header *lh = cu->line_header;
Will> +  struct attribute *attr = dwarf2_attr (die, DW_AT_stmt_list, cu);
Will> +  if (lh == nullptr && attr != nullptr && attr->form_is_unsigned ())
Will> +    {
Will> +      sect_offset line_offset = (sect_offset) attr->as_unsigned ();
Will> +      line_header_up lhu = dwarf_decode_line_header (line_offset, cu,
Will> +				     res.get_comp_dir ());
Will> +      if (lhu != nullptr)
Will> +	  lh = lhu.release();

This will leak memory.

However if this is the first time reading the header, should it be
stashed somewhere?  It seems to me it shouldn't have to be read more
than once.

IOW, how does this case get reached?

Will> +/* See source.h.  */
Will> +
Will> +char *
Will> +embedded_fullname (const char *dirname, const char *filename)

Should return a unique_xmalloc_ptr<char>

Will> +{
Will> +  if (dirname != nullptr)
Will> +    {
Will> +      return concat (dirname, SLASH_STRING, filename, (char *) nullptr);
Will> +    }

No braces needed.

Will> +
Will> +  return xstrdup (filename);

make_unique_xstrdup

thanks,
Tom

  parent reply	other threads:[~2024-04-19 20:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-12 18:55 Will Hawkins
2024-04-12 20:12 ` Tom de Vries
2024-04-14  2:50   ` Will Hawkins
2024-04-14  7:01     ` Tom de Vries
2024-04-14  7:15       ` Will Hawkins
2024-04-15 16:13         ` Will Hawkins
2024-04-19 20:17 ` Tom Tromey [this message]
2024-04-26  6:12   ` Will Hawkins

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=87ttjxt8eb.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=gdb-patches@sourceware.org \
    --cc=hawkinsw@obs.cr \
    /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).