[PATCH v4 08/14] Use NT_FILE note section for reading core target memory

Pedro Alves pedro@palves.net
Fri Jul 10 20:08:27 GMT 2020


On 7/5/20 11:58 PM, Kevin Buettner via Gdb-patches wrote:

> +void
> +core_target::build_file_mappings ()
> +{
> +  std::unordered_map<std::string, struct bfd *> bfd_map;
> +
> +  /* See linux_read_core_file_mappings() in linux-tdep.c for an example
> +     read_core_file_mappings method.  */
> +  gdbarch_read_core_file_mappings (m_core_gdbarch, core_bfd,
> +
> +    /* After determining the number of mappings, read_core_file_mappings
> +       will invoke this lambda which allocates target_section storage for
> +       the mappings.  */
> +    [&] (ULONGEST count)
> +      {
> +	m_core_file_mappings.sections = XNEWVEC (struct target_section, count);
> +	m_core_file_mappings.sections_end = m_core_file_mappings.sections;
> +      },
> +
> +    /* read_core_file_mappings will invoke this lambda for each mapping
> +       that it finds.  */
> +    [&] (int num, ULONGEST start, ULONGEST end, ULONGEST file_ofs,
> +         const char *filename, const void *other)
> +      {
> +	/* Architecture-specific read_core_mapping methods are expected to
> +	   weed out non-file-backed mappings.  */
> +	gdb_assert (filename != nullptr);
> +
> +	struct bfd *bfd = bfd_map[filename];
> +	if (bfd == nullptr) {

Brace on next line.

> +
> +	  /* Use exec_file_find() to do sysroot expansion.  It'll also strip
> +	     the potential sysroot target: prefix.  If there is no sysroot, an
> +	     equivalent (possibly more canonical) pathname will be provided.  */
> +	  gdb::unique_xmalloc_ptr<char> expanded_fname
> +	    = exec_file_find (filename, NULL);
> +	  if (expanded_fname == nullptr)
> +	    {
> +	      warning (_("Can't open file %s during file-backed mapping "
> +	                 "note processing"),
> +		       expanded_fname.get ());
> +	      return;
> +	    }
> +
> +	  bfd = bfd_map[filename] = bfd_openr (expanded_fname.get (), "binary");
> +
> +	  if (bfd == nullptr || !bfd_check_format (bfd, bfd_object))
> +	    {
> +	      /* If we get here, there's a good chance that it's due to
> +		 an internal error.  We issue a warning instead of an
> +		 internal error because of the possibility that the
> +		 file was removed in between checking for its
> +		 existence during the expansion in exec_file_find()
> +		 and the calls to bfd_openr() / bfd_check_format(). 
> +		 Output both the path from the core file note along
> +		 with its expansion to make debugging this problem
> +		 easier.  */
> +	      warning (_("Can't open file %s which was expanded to %s "
> +			 "during file-backed mapping note processing"),
> +		       filename, expanded_fname.get ());
> +	      return;

Don't we have to close the bfd if it was opened, but failed the
bfd_check_format check?

> +	    }
> +	    /* Ensure that the bfd will be closed when core_bfd is closed. 
> +	       This can be checked before/after a core file detach via
> +	       "maint info bfds".  */
> +	    gdb_bfd_record_inclusion (core_bfd, bfd);
> +	}
> +
> +	/* Make new BFD section.  */
> +	char secnamebuf[64];
> +	sprintf (secnamebuf, "S%04d", num);
> +	char *secname = (char *) bfd_alloc (bfd, strlen (secnamebuf) + 1);
> +	if (secname == nullptr)
> +	  error (_("Out of memory"));
> +	strcpy (secname, secnamebuf);
> +	asection *sec = bfd_make_section_anyway (bfd, secname);
> +	if (sec == nullptr)
> +	  error (_("Can't make section"));

SECNAME leaks if you throw here.  Use a unique pointer?
Also, should these be malloc_failure instead?

> +	sec->filepos = file_ofs;
> +	bfd_set_section_flags (sec, SEC_READONLY | SEC_HAS_CONTENTS);
> +	bfd_set_section_size (sec, end - start);
> +	bfd_set_section_vma (sec, start);
> +	bfd_set_section_lma (sec, start);
> +	bfd_set_section_alignment (sec, 2);
> +
> +	/* Set target_section fields.  */
> +	struct target_section *ts = m_core_file_mappings.sections_end++;
> +	ts->addr = start;
> +	ts->endaddr = end;
> +	ts->owner = nullptr;
> +	ts->the_bfd_section = sec;
> +      });
>  }
>  

Otherwise LGTM.


More information about the Gdb-patches mailing list