Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: Fernando Nasser <fnasser@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] arm-tdep.c: deal with failed memory read
Date: Tue, 27 Nov 2001 20:00:00 -0000	[thread overview]
Message-ID: <3C04615A.7020304@cygnus.com> (raw)
Message-ID: <20011127200000.GghO2zIYR37vT0qwdMxmgfLsIQHG6s0Rvj6fP7YrI3E@z> (raw)
In-Reply-To: <3BFEB3EB.816139A1@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.

We desperatly need a better naming convention and clearer semantics 
(what happens if the function fails due to a target disconnect) for 
these wrapped functions.  gdb_*() is being used by both libgdb and 
wrapper.[hc] et.al.

Suggestions?

Otherwize ok.

	Andrew


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



  reply	other threads:[~2001-11-27 20:00 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
2001-11-15 12:54   ` Andrew Cagney [this message]
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=3C04615A.7020304@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=ezannoni@cygnus.com \
    --cc=fnasser@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