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

On Monday 14 February 2011 12:00:00, Jan Kratochvil wrote:

> > +	  /* Fallback to reading from read-only sections.  */
> > +	  table = target_get_section_table (&exec_ops);
> 
> Cannot be table NULL?

The exec target always returns a non-NULL table.  It may
be empty though (sections == sections_end).

> > +	  available_memory =
> > +	    section_table_available_memory (available_memory,
> > +					    memaddr, length,
> > +					    table->sections,
> > +					    table->sections_end);
> > +

> >  
> > +/* 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.

Thanks.  I've renamed s/offset/embedded_offset in the declaration.

> 
> 
> > @@ -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.

I think these parameters are the least of your troubles,
given than you'll need to fix at least all the struct value
related code for that.  Made it a ULONGEST.

> Unused variable `memend'.

Deleted.

I checked in the patch below.  Thanks!

-- 
Pedro Alves

2011-02-14  Pedro Alves  <pedro@codesourcery.com>
	    Jan Kratochvil  <jan.kratochvil@redhat.com>

	gdb/
	* exec.c (section_table_available_memory): Change `len' parameter
	type to ULONGEST.
	* exec.h (section_table_available_memory): Ditto.
	* value.h (read_value_memory): Rename the `offset' parameter to
	`embedded_offset'.

---
 gdb/exec.c  |    3 +--
 gdb/exec.h  |    2 +-
 gdb/value.h |    2 +-
 3 files changed, 3 insertions(+), 4 deletions(-)

Index: src/gdb/exec.c
===================================================================
--- src.orig/gdb/exec.c	2011-02-14 11:20:34.000000000 +0000
+++ src/gdb/exec.c	2011-02-14 21:54:43.843995012 +0000
@@ -574,12 +574,11 @@ map_vmap (bfd *abfd, bfd *arch)
 
 VEC(mem_range_s) *
 section_table_available_memory (VEC(mem_range_s) *memory,
-				CORE_ADDR memaddr, LONGEST len,
+				CORE_ADDR memaddr, ULONGEST len,
 				struct target_section *sections,
 				struct target_section *sections_end)
 {
   struct target_section *p;
-  ULONGEST memend = memaddr + len;
 
   for (p = sections; p < sections_end; p++)
     {
Index: src/gdb/exec.h
===================================================================
--- src.orig/gdb/exec.h	2011-02-14 11:20:34.000000000 +0000
+++ src/gdb/exec.h	2011-02-14 21:53:45.573994995 +0000
@@ -52,7 +52,7 @@ extern int resize_section_table (struct
 
 extern VEC(mem_range_s) *
   section_table_available_memory (VEC(mem_range_s) *ranges,
-				  CORE_ADDR memaddr, LONGEST len,
+				  CORE_ADDR memaddr, ULONGEST len,
 				  struct target_section *sections,
 				  struct target_section *sections_end);
 
Index: src/gdb/value.h
===================================================================
--- src.orig/gdb/value.h	2011-02-14 11:32:21.000000000 +0000
+++ src/gdb/value.h	2011-02-14 21:51:17.783995011 +0000
@@ -410,7 +410,7 @@ extern int value_available_contents_eq (
    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,
+extern void read_value_memory (struct value *val, int embedded_offset,
 			       int stack, CORE_ADDR memaddr,
 			       gdb_byte *buffer, size_t length);
 


  reply	other threads:[~2011-02-14 22:11 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
2011-02-14 22:14   ` Pedro Alves [this message]
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=201102142211.11899.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.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