From: Andrew Cagney <ac131313@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: [patch/rfc] Add frame_read_signed/unsigned_register()
Date: Thu, 31 Oct 2002 12:11:00 -0000 [thread overview]
Message-ID: <3DC18E8C.7040300@redhat.com> (raw)
In-Reply-To: <3DB610B9.5040906@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 795 bytes --]
> Hmm,
>
> (I think I might split this in two)
>
> The attached adds the methods:
>
> +extern void frame_read_signed_register (struct frame_info *frame,
> + int regnum, LONGEST *val);
> +extern void frame_read_unsigned_register (struct frame_info *frame,
> + int regnum, ULONGEST *val);
>
> These correspond to the frame_unwind_XXXX methods() except that they return the value of a register in THIS frame rather than the value of the register in the PREVIOUS frame.
>
> They are simply convenience functions to make it easier to obtain a specified frame's register value.
>
> Thoughts?
I've checked in the attatched. The additional comment and assertion
should address the questions DanielJ raised.
Andrew
[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 3213 bytes --]
2002-10-31 Andrew Cagney <cagney@redhat.com>
* frame.c (frame_read_unsigned_register): New function.
(frame_read_signed_register): New function.
* frame.h (frame_read_unsigned_register): Declare.
(frame_read_signed_register): Declare.
Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.18
diff -u -r1.18 frame.c
--- frame.c 25 Sep 2002 20:30:37 -0000 1.18
+++ frame.c 31 Oct 2002 19:53:11 -0000
@@ -153,6 +153,40 @@
}
void
+frame_read_unsigned_register (struct frame_info *frame, int regnum,
+ ULONGEST *val)
+{
+ /* NOTE: cagney/2002-10-31: There is a bit of dogma here - there is
+ always a frame. Both this, and the equivalent
+ frame_read_signed_register() function, can only be called with a
+ valid frame. If, for some reason, this function is called
+ without a frame then the problem isn't here, but rather in the
+ caller. It should of first created a frame and then passed that
+ in. */
+ /* NOTE: cagney/2002-10-31: As a side bar, keep in mind that the
+ ``current_frame'' should not be treated as a special case. While
+ ``get_next_frame (current_frame) == NULL'' currently holds, it
+ should, as far as possible, not be relied upon. In the future,
+ ``get_next_frame (current_frame)'' may instead simply return a
+ normal frame object that simply always gets register values from
+ the register cache. Consequently, frame code should try to avoid
+ tests like ``if get_next_frame() == NULL'' and instead just rely
+ on recursive frame calls (like the below code) when manipulating
+ a frame chain. */
+ gdb_assert (frame != NULL);
+ frame_unwind_unsigned_register (get_next_frame (frame), regnum, val);
+}
+
+void
+frame_read_signed_register (struct frame_info *frame, int regnum,
+ LONGEST *val)
+{
+ /* See note in frame_read_unsigned_register(). */
+ gdb_assert (frame != NULL);
+ frame_unwind_signed_register (get_next_frame (frame), regnum, val);
+}
+
+void
generic_unwind_get_saved_register (char *raw_buffer,
int *optimizedp,
CORE_ADDR *addrp,
Index: frame.h
===================================================================
RCS file: /cvs/src/src/gdb/frame.h,v
retrieving revision 1.26
diff -u -r1.26 frame.h
--- frame.h 2 Oct 2002 21:33:58 -0000 1.26
+++ frame.h 31 Oct 2002 19:53:11 -0000
@@ -366,6 +366,16 @@
extern int frame_register_read (struct frame_info *frame, int regnum,
void *buf);
+/* Return the value of register REGNUM that belongs to FRAME. The
+ value is obtained by unwinding the register from the next / more
+ inner frame. */
+/* NOTE: cagney/2002-09-13: Return void as one day these functions may
+ be changed to return an indication that the read succeeded. */
+extern void frame_read_signed_register (struct frame_info *frame,
+ int regnum, LONGEST *val);
+extern void frame_read_unsigned_register (struct frame_info *frame,
+ int regnum, ULONGEST *val);
+
/* Map between a frame register number and its name. A frame register
space is a superset of the cooked register space --- it also
includes builtin registers. */
next prev parent reply other threads:[~2002-10-31 20:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-22 20:00 [patch/rfc] Add frame_read_signed/unsigned_register(); convert h8300 to print_registers_info() Andrew Cagney
2002-10-23 8:21 ` Daniel Jacobowitz
2002-10-23 9:48 ` NULL selected/current frame; Was: " Andrew Cagney
2002-10-23 9:50 ` Daniel Jacobowitz
2002-10-31 12:11 ` Andrew Cagney [this message]
2002-10-31 12:24 ` [patch] Convert " Andrew Cagney
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=3DC18E8C.7040300@redhat.com \
--to=ac131313@redhat.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