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);
next prev parent 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