From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: palves@redhat.com (Pedro Alves)
Cc: emachado@linux.vnet.ibm.com (Edjunior Barbosa Machado),
gdb-patches@sourceware.org
Subject: Re: [PATCH] [PR tdep/17379] Fix internal-error when stack pointer is invalid
Date: Wed, 17 Sep 2014 12:41:00 -0000 [thread overview]
Message-ID: <201409171241.s8HCfHqs007521@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <54195D36.2080001@redhat.com> from "Pedro Alves" at Sep 17, 2014 11:06:46 AM
Pedro Alves wrote:
> See https://sourceware.org/bugzilla/show_bug.cgi?id=17384 .
>
> When safe_read_memory_integer call fails, GDB prints a
> surprising/confusing error message, more so in case the unwinder
> is triggered for some reason other than the "bt" command, like
> with "step"/"next". I take you're now seeing the same errors
> with this patch.
>
> IMO, printing the error is not something a low-level helper function
> like safe_read_memory_integer should be doing, as GDB uses it when
> probing with heuristics because it can't sure its guesses make sense
> (whether there's a frame at all, etc.) safe_frame_unwind_memory, which is
> used in rs6000_in_function_epilogue_p doesn't print the error either.
Agreed, it doesn't make sense for safe_read_memory_integer to ever
print an error. In fact, it doesn't make sense for it to start
using a routine that raises exceptions and then attempt to catch it.
The following patch simplifies the whole logic by just using
target_read_memory directly. Does this look reasonable?
[ B.t.w. the naming of safe_frame_unwind_memory is a bit weird. This
should either be "safe_read_memory" in corefile.c, or else something
like safe_get_frame_memory in analogy to get_frame_memory. ]
Tested on powerpc64le-linux.
Bye,
Ulrich
gdb/ChangeLog:
* corefile.c (struct captured_read_memory_integer_arguments): Remove.
(do_captured_read_memory_integer): Remove.
(safe_read_memory_integer): Use target_read_memory directly instead
of catching errors in do_captured_read_memory_integer.
diff --git a/gdb/corefile.c b/gdb/corefile.c
index 1617392..a0bb2aa 100644
--- a/gdb/corefile.c
+++ b/gdb/corefile.c
@@ -290,40 +290,6 @@ read_code (CORE_ADDR memaddr, gdb_byte *myaddr, ssize_t len)
memory_error (status, memaddr);
}
-/* Argument / return result struct for use with
- do_captured_read_memory_integer(). MEMADDR and LEN are filled in
- by gdb_read_memory_integer(). RESULT is the contents that were
- successfully read from MEMADDR of length LEN. */
-
-struct captured_read_memory_integer_arguments
-{
- CORE_ADDR memaddr;
- int len;
- enum bfd_endian byte_order;
- LONGEST result;
-};
-
-/* Helper function for gdb_read_memory_integer(). DATA must be a
- pointer to a captured_read_memory_integer_arguments struct.
- Return 1 if successful. Note that the catch_errors() interface
- will return 0 if an error occurred while reading memory. This
- choice of return code is so that we can distinguish between
- success and failure. */
-
-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;
- enum bfd_endian byte_order = args->byte_order;
-
- args->result = read_memory_integer (memaddr, len, byte_order);
-
- return 1;
-}
-
/* Read memory at MEMADDR of length LEN and put the contents in
RETURN_VALUE. Return 0 if MEMADDR couldn't be read and non-zero
if successful. */
@@ -333,19 +299,13 @@ safe_read_memory_integer (CORE_ADDR memaddr, int len,
enum bfd_endian byte_order,
LONGEST *return_value)
{
- int status;
- struct captured_read_memory_integer_arguments args;
-
- args.memaddr = memaddr;
- args.len = len;
- args.byte_order = byte_order;
+ gdb_byte buf[sizeof (LONGEST)];
- status = catch_errors (do_captured_read_memory_integer, &args,
- "", RETURN_MASK_ALL);
- if (status)
- *return_value = args.result;
+ if (target_read_memory (memaddr, buf, len))
+ return 0;
- return status;
+ *return_value = extract_signed_integer (buf, len, byte_order);
+ return 1;
}
LONGEST
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com
next parent reply other threads:[~2014-09-17 12:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <54195D36.2080001@redhat.com>
2014-09-17 12:41 ` Ulrich Weigand [this message]
2014-09-17 13:03 ` Pedro Alves
2014-09-17 15:34 ` [PUSHED][PR gdb/17384] " Ulrich Weigand
2014-09-11 23:03 Edjunior Barbosa Machado
2014-09-11 23:21 ` Sergio Durigan Junior
2014-09-12 2:47 ` Edjunior Barbosa Machado
2014-09-12 3:20 ` Sergio Durigan Junior
2014-09-12 8:39 ` Ulrich Weigand
2014-09-12 9:59 ` Pedro Alves
2014-09-12 12:31 ` Edjunior Barbosa Machado
2014-09-12 13:00 ` Joel Brobecker
2014-09-12 13:38 ` Pedro Alves
2014-09-12 13:50 ` Joel Brobecker
2014-09-12 14:21 ` Pedro Alves
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=201409171241.s8HCfHqs007521@d06av02.portsmouth.uk.ibm.com \
--to=uweigand@de.ibm.com \
--cc=emachado@linux.vnet.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@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