Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [unavailable values part 1, 04/17] map unavailable memory to unavailable value contents
Date: Mon, 14 Feb 2011 12:00:00 -0000	[thread overview]
Message-ID: <20110214115958.GD2454@host1.dyn.jankratochvil.net> (raw)
In-Reply-To: <201102071429.40838.pedro@codesourcery.com>

> @@ -1009,12 +1009,8 @@ value_fetch_lazy (struct value *val)
>        int length = TYPE_LENGTH (check_typedef (value_enclosing_type (val)));
>  
>        if (length)
> -	{
> -	  if (value_stack (val))
> -	    read_stack (addr, value_contents_all_raw (val), length);
> -	  else
> -	    read_memory (addr, value_contents_all_raw (val), length);
> -	}
> +	read_value_memory (val, 0, value_stack (val),
> +			   addr, value_contents_all_raw (val), length);

I think here should be value_contents_raw.  It is an unrelated issue.


>      }
>    else if (VALUE_LVAL (val) == lval_register)
>      {
> @@ -1113,6 +1109,89 @@ value_fetch_lazy (struct value *val)
>    return 0;
>  }
>  
> +void
> +read_value_memory (struct value *val, int embedded_offset,
> +		   int stack, CORE_ADDR memaddr,
> +		   gdb_byte *buffer, size_t length)
> +{
> +  if (length)
> +    {
> +      VEC(mem_range_s) *available_memory;
> +
> +      if (get_traceframe_number () < 0
> +	  || !traceframe_available_memory (&available_memory, memaddr, length))
> +	{
> +	  if (stack)
> +	    read_stack (memaddr, buffer, length);
> +	  else
> +	    read_memory (memaddr, buffer, length);
> +	}
> +      else
> +	{
> +	  struct target_section_table *table;
> +	  struct cleanup *old_chain;
> +	  CORE_ADDR unavail;
> +	  mem_range_s *r;
> +	  int i;
> +
> +	  /* Fallback to reading from read-only sections.  */
> +	  table = target_get_section_table (&exec_ops);

Cannot be table NULL?


> +	  available_memory =
> +	    section_table_available_memory (available_memory,
> +					    memaddr, length,
> +					    table->sections,
> +					    table->sections_end);
> +
> +	  old_chain = make_cleanup (VEC_cleanup(mem_range_s),
> +				    &available_memory);
> +


> --- src.orig/gdb/value.h	2011-02-07 11:12:35.406706000 +0000
> +++ src/gdb/value.h	2011-02-07 11:15:02.926705996 +0000
> @@ -374,6 +374,17 @@ extern int value_bytes_available (const
>  extern void mark_value_bytes_unavailable (struct value *value,
>  					  int offset, int length);
>  
> +/* Read LENGTH bytes of memory starting at MEMADDR into BUFFER, which
> +   is (or will be copied to) VAL's contents buffer offset by
> +   EMBEDDED_OFFSET (that is, to &VAL->contents[EMBEDDED_OFFSET]).
> +   Marks value contents ranges as unavailable if the corresponding
> +   memory is likewise unavailable.  STACK indicates whether the memory
> +   is known to be stack memory.  */
> +
> +extern void read_value_memory (struct value *val, int offset,
> +			       int stack, CORE_ADDR memaddr,
> +			       gdb_byte *buffer, size_t length);
> +

Comment talks about EMBEDDED_OFFSET while the declaration parameter name does
not match the function definition parameter name.


> @@ -572,6 +572,43 @@ map_vmap (bfd *abfd, bfd *arch)
>  }
>  \f
>  
> +VEC(mem_range_s) *
> +section_table_available_memory (VEC(mem_range_s) *memory,
> +				CORE_ADDR memaddr, LONGEST len,

After `int', `ULONGEST' and `size_t' the type is now `LONGEST'.

Does it mean there is no intention for >2GB inferior objects handling?
I thought some Fortran simulations may use such arrays etc.


> +				struct target_section *sections,
> +				struct target_section *sections_end)
> +{
> +  struct target_section *p;
> +  ULONGEST memend = memaddr + len;

Unused variable `memend'.

> +
> +  for (p = sections; p < sections_end; p++)
> +    {
> +      if ((bfd_get_section_flags (p->bfd, p->the_bfd_section)
> +	   & SEC_READONLY) == 0)
> +	continue;
> +
> +      /* Copy the meta-data, adjusted.  */
> +      if (mem_ranges_overlap (p->addr, p->endaddr - p->addr, memaddr, len))
> +	{
> +	  ULONGEST lo1, hi1, lo2, hi2;
> +	  struct mem_range *r;
> +
> +	  lo1 = memaddr;
> +	  hi1 = memaddr + len;
> +
> +	  lo2 = p->addr;
> +	  hi2 = p->endaddr;
> +
> +	  r = VEC_safe_push (mem_range_s, memory, NULL);
> +
> +	  r->start = max (lo1, lo2);
> +	  r->length = min (hi1, hi2) - r->start;
> +	}
> +    }
> +
> +  return memory;
> +}


Thanks,
Jan


  reply	other threads:[~2011-02-14 12:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-07 14:29 Pedro Alves
2011-02-14 12:00 ` Jan Kratochvil [this message]
2011-02-14 22:14   ` Pedro Alves
2011-02-14 22:30     ` Jan Kratochvil

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=20110214115958.GD2454@host1.dyn.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.com \
    /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