Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Fernando Nasser <fnasser@cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] arm-tdep.c: deal with failed memory read
Date: Sat, 10 Nov 2001 10:13:00 -0000	[thread overview]
Message-ID: <3BFEB3EB.816139A1@cygnus.com> (raw)
In-Reply-To: <15356.17915.602742.140302@krustylu.cygnus.com>

Elena Zannoni wrote:
> 
> If, upon initial connection to a remote ARM target, the contents of
> r11 (which is the Frame Pointer) are junk, a memory read from
> arm_scan_prologue can fail and abort the whole connection to the
> remote target. There are several ways to fix this, and probably the
> most correct one is to teach gdb to do the initial connection in 2
> separate steps. First connect and declare that successful or not, then
> start reading memory if the connection was established.
> 
> This patch is just a band-aid to allow intercepting bad memory reads
> and not aborting the connection.  It has been in our internal
> repository for a couple of months now. It is by no means a complete
> solution, but it improves things a bit.
> 
> OK?
> 

The arm-tdep.c part is approved.

Fernando


> Elena
> 
> 2001-11-21  Elena Zannoni  <ezannoni@redhat.com>
> 
>         * corefile.c (do_captured_read_memory_integer,
>         gdb_read_memory_integer): New functions.
>         * gdbcore.h (gdb_read_memory_integer): Export.
>         * arm-tdep.c (arm_scan_prologue): Use gdb_read_memory_integer,
>         to read the frame value, to capture calls to error().
> 
> Index: arm-tdep.c
> ===================================================================
> RCS file: /cvs/uberbaum/gdb/arm-tdep.c,v
> retrieving revision 1.17
> diff -u -p -r1.17 arm-tdep.c
> --- arm-tdep.c  2001/11/14 08:18:32     1.17
> +++ arm-tdep.c  2001/11/22 00:08:28
> @@ -717,6 +717,7 @@ static void
>  arm_scan_prologue (struct frame_info *fi)
>  {
>    int regno, sp_offset, fp_offset;
> +  LONGEST return_value;
>    CORE_ADDR prologue_start, prologue_end, current_pc;
> 
>    /* Check if this function is already in the cache of frame information. */
> @@ -781,9 +782,13 @@ arm_scan_prologue (struct frame_info *fi
>      {
>        /* Get address of the stmfd in the prologue of the callee; the saved
>           PC is the address of the stmfd + 8.  */
> -      prologue_start = ADDR_BITS_REMOVE (read_memory_integer (fi->frame, 4))
> -       - 8;
> -      prologue_end = prologue_start + 64;      /* See above. */
> +      if (!gdb_read_memory_integer (fi->frame, 4,  &return_value))
> +       return;
> +      else
> +       {
> +         prologue_start = ADDR_BITS_REMOVE (return_value) - 8;
> +         prologue_end = prologue_start + 64;   /* See above. */
> +       }
>      }
> 
>    /* Now search the prologue looking for instructions that set up the
> Index: corefile.c
> ===================================================================
> RCS file: /cvs/uberbaum/gdb/corefile.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 corefile.c
> --- corefile.c  2001/11/12 21:08:04     1.15
> +++ corefile.c  2001/11/22 00:08:50
> @@ -262,6 +262,41 @@ dis_asm_print_address (bfd_vma addr, str
> 
>  /* Read an integer from debugged memory, given address and number of bytes.  */
> 
> +struct captured_read_memory_integer_arguments
> +{
> +  CORE_ADDR memaddr;
> +  int len;
> +  LONGEST result;
> +};
> +
> +static int
> +do_captured_read_memory_integer (void *data)
> +{
> +  struct captured_read_memory_integer_arguments *args = (struct captured_read_memory_integer_arguments*) data
> ;
> +  CORE_ADDR memaddr = args->memaddr;
> +  int len = args->len;
> +
> +  args->result = read_memory_integer (memaddr, len);
> +
> +  return 0;
> +}
> +
> +int
> +gdb_read_memory_integer (CORE_ADDR memaddr, int len, LONGEST *return_value)
> +{
> +  int status;
> +  struct captured_read_memory_integer_arguments args;
> +  args.memaddr = memaddr;
> +  args.len = len;
> +
> +  status = catch_errors (do_captured_read_memory_integer, &args,
> +                        "", RETURN_MASK_ALL);
> +  if (!status)
> +    *return_value = args.result;
> +
> +  return status;
> +}
> +
>  LONGEST
>  read_memory_integer (CORE_ADDR memaddr, int len)
>  {
> Index: gdbcore.h
> ===================================================================
> RCS file: /cvs/uberbaum/gdb/gdbcore.h,v
> retrieving revision 1.8
> diff -u -p -r1.8 gdbcore.h
> --- gdbcore.h   2001/11/12 21:08:04     1.8
> +++ gdbcore.h   2001/11/22 00:09:12
> @@ -55,6 +55,7 @@ extern void read_memory (CORE_ADDR memad
>     bytes.  */
> 
>  extern LONGEST read_memory_integer (CORE_ADDR memaddr, int len);
> +extern int gdb_read_memory_integer (CORE_ADDR memaddr, int len, LONGEST *return_value);
> 
>  /* Read an unsigned integer from debugged memory, given address and
>     number of bytes.  */

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9


  reply	other threads:[~2001-11-23 20:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-09  1:18 Elena Zannoni
2001-11-10 10:13 ` Fernando Nasser [this message]
2001-11-15 12:54   ` Andrew Cagney
2001-11-27 20:00     ` Andrew Cagney
2001-11-28 12:25     ` Andrew Cagney
2001-11-17 20:44       ` Andrew Cagney
2001-12-19 15:54       ` Elena Zannoni
2001-12-05 14:41     ` Elena Zannoni

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=3BFEB3EB.816139A1@cygnus.com \
    --to=fnasser@cygnus.com \
    --cc=ezannoni@cygnus.com \
    --cc=gdb-patches@sources.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