Re: RFC: implement 'info proc mappings' for core files

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Tue, 20 Nov 2012 21:05:33 +0100, Tom Tromey wrote:
> diff --git a/gdb/corelow.c b/gdb/corelow.c
> index 99611ba..1645858 100644
> --- a/gdb/corelow.c
> +++ b/gdb/corelow.c
> @@ -927,6 +927,17 @@ core_has_registers (struct target_ops *ops)
>    return (core_bfd != NULL);
>  }
>  
> +/* Implement the to_info_proc method.  */
> +
> +static void
> +core_info_proc (struct target_ops *ops, char *args, enum info_proc_what request)
> +{
> +  struct gdbarch *gdbarch = get_current_arch ();
> +

It was not much clear to me first:

/* As this is core file target here we call core_info_proc from gdbarch, not
   info_proc.  Despite we are target_info_proc implementation.  */

> +  if (gdbarch_core_info_proc_p (gdbarch))
> +    gdbarch_core_info_proc (gdbarch, args, request);
> +}
> +
>  /* Fill in core_ops with its defined operations and properties.  */
>  
>  static void
> @@ -953,6 +964,7 @@ init_core_ops (void)
>    core_ops.to_has_memory = core_has_memory;
>    core_ops.to_has_stack = core_has_stack;
>    core_ops.to_has_registers = core_has_registers;
> +  core_ops.to_info_proc = core_info_proc;
>    core_ops.to_magic = OPS_MAGIC;
>  
>    if (core_target)
> --- a/gdb/gdbarch.sh
> +++ b/gdb/gdbarch.sh
> @@ -943,6 +943,9 @@ m:void:gen_return_address:struct agent_expr *ax, struct axs_value *value, CORE_A
>  # Implement the "info proc" command.
>  M:void:info_proc:char *args, enum info_proc_what what:args, what
>  
> +# Implement the "info proc" command for core files.
> +M:void:core_info_proc:char *args, enum info_proc_what what:args, what
> +

Here maybe a comment

# There exists only target_info_proc but there are two gdbarch methods for it.


>  # Iterate over all objfiles in the order that makes the most sense
>  # for the architecture to make global symbol searches.
>  #
[...]
> --- a/gdb/linux-tdep.c
> +++ b/gdb/linux-tdep.c
> @@ -30,6 +30,8 @@
>  #include "elf-bfd.h"            /* for elfcore_write_* */
>  #include "inferior.h"
>  #include "cli/cli-utils.h"
> +#include "arch-utils.h"
> +#include "gdb_obstack.h"
>  
>  #include <ctype.h>
>  
> @@ -533,11 +535,149 @@ linux_info_proc (struct gdbarch *gdbarch, char *args,
>      }
>  }
>  
> +/* Implement "info proc mappings" for a corefile.  */
> +
> +static void
> +linux_core_info_proc_mappings (struct gdbarch *gdbarch, char *args)
> +{
> +  asection *section;
> +  ULONGEST count, page_size;
> +  unsigned char *descdata, *filenames, *descend, *contents;
> +  size_t note_size;
> +  unsigned int addr_size_bits, addr_size;
> +  struct cleanup *cleanup;
> +  struct gdbarch *core_gdbarch = gdbarch_from_bfd (core_bfd);
> +
> +  section = bfd_get_section_by_name (core_bfd, ".note.linuxcore.file");
> +  if (section == NULL)
> +    {
> +      warning (_("unable to find mappings in core file"));
> +      return;
> +    }
> +
> +  if (gdbarch_addr_bit (core_gdbarch) == 32 && sizeof (ULONGEST) < 8)
> +    error (_("cannot decode 64-bit core note in 32-bit gdb"));

Here you probably meant gdbarch_addr_bit == 64.

But there was a discussion with pending patch GDB cannot be compiled without
"long long" anyway resulting in:
	[patch] Require long long for GDB [Re: [patch] Compilation regression on older gcc + 32-bit host]
	Message-ID: <20120531154019.GA16401@host2.jankratochvil.net>
	http://sourceware.org/ml/gdb-patches/2012-05/msg01094.html

I should check in that patch but it had no more comments.

So 'sizeof (ULONGEST) < 8' can never happen.


> +
> +  addr_size_bits = gdbarch_addr_bit (core_gdbarch);
> +  addr_size = addr_size_bits / 8;
> +  note_size = bfd_get_section_size (section);
> +
> +  if (note_size < 2 * addr_size)
> +    error (_("malformed core note - too short for header"));
> +
> +  contents = xmalloc (note_size);
> +  cleanup = make_cleanup (xfree, contents);
> +  if (!bfd_get_section_contents (core_bfd, section, contents, 0, note_size))
> +    error (_("could not get core note contents"));
[...]
> +typedef int (*linux_find_memory_region_ftype) (ULONGEST vaddr, ULONGEST size,

*_ftype named typedefs in GDB are without the pointer.


> +					       ULONGEST offset, ULONGEST inode,
> +					       int read, int write,
> +					       int exec, int modified,
> +					       const char *filename,
> +					       void *data);
> +
>  /* List memory regions in the inferior for a corefile.  */
>  
>  static int
> -linux_find_memory_regions (struct gdbarch *gdbarch,
> -			   find_memory_region_ftype func, void *obfd)
> +linux_find_memory_regions_full (struct gdbarch *gdbarch,
> +				linux_find_memory_region_ftype func, void *obfd)
>  {
>    char filename[100];
>    gdb_byte *data;
[...]
> +/* A callback for linux_find_memory_regions_full that updates the
> +   mappings data for linux_make_mappings_corefile_notes.  */
> +

And here could be then
	static linux_find_memory_region_ftype linux_make_mappings_callback;

To (also) see in editor all the instances of that *_ftype.


> +static int
> +linux_make_mappings_callback (ULONGEST vaddr, ULONGEST size,
> +			      ULONGEST offset, ULONGEST inode,
> +			      int read, int write, int exec, int modified,
> +			      const char *filename, void *data)
> +{
[...]


Thanks,
Jan