* [pushed] gdb: make frame_register static
@ 2022-12-01 18:32 Simon Marchi
2022-12-06 14:52 ` Lancelot SIX
0 siblings, 1 reply; 3+ messages in thread
From: Simon Marchi @ 2022-12-01 18:32 UTC (permalink / raw)
To: gdb-patches; +Cc: Simon Marchi
From: Simon Marchi <simon.marchi@polymtl.ca>
It is only used inside frame.c.
Change-Id: I44eb46a5992412f8f8b4954b2284b0ef3b549504
---
gdb/frame.c | 7 ++++++-
gdb/frame.h | 11 -----------
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/gdb/frame.c b/gdb/frame.c
index c8c4ec817a42..b4079ef833e8 100644
--- a/gdb/frame.c
+++ b/gdb/frame.c
@@ -1166,7 +1166,12 @@ frame_register_unwind (frame_info_ptr next_frame, int regnum,
release_value (value);
}
-void
+/* Get the value of the register that belongs to this FRAME. This
+ function is a wrapper to the call sequence ``frame_register_unwind
+ (get_next_frame (FRAME))''. As per frame_register_unwind(), if
+ VALUEP is NULL, the registers value is not fetched/computed. */
+
+static void
frame_register (frame_info_ptr frame, int regnum,
int *optimizedp, int *unavailablep, enum lval_type *lvalp,
CORE_ADDR *addrp, int *realnump, gdb_byte *bufferp)
diff --git a/gdb/frame.h b/gdb/frame.h
index 6b841fd50636..100ab1fe48eb 100644
--- a/gdb/frame.h
+++ b/gdb/frame.h
@@ -511,17 +511,6 @@ extern ULONGEST get_frame_register_unsigned (frame_info_ptr frame,
extern bool read_frame_register_unsigned (frame_info_ptr frame,
int regnum, ULONGEST *val);
-/* Get the value of the register that belongs to this FRAME. This
- function is a wrapper to the call sequence ``frame_register_unwind
- (get_next_frame (FRAME))''. As per frame_register_unwind(), if
- VALUEP is NULL, the registers value is not fetched/computed. */
-
-extern void frame_register (frame_info_ptr frame, int regnum,
- int *optimizedp, int *unavailablep,
- enum lval_type *lvalp,
- CORE_ADDR *addrp, int *realnump,
- gdb_byte *valuep);
-
/* The reverse. Store a register value relative to the specified
frame. Note: this call makes the frame's state undefined. The
register and frame caches must be flushed. */
--
2.38.1
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [pushed] gdb: make frame_register static
2022-12-01 18:32 [pushed] gdb: make frame_register static Simon Marchi
@ 2022-12-06 14:52 ` Lancelot SIX
2022-12-06 15:43 ` Simon Marchi
0 siblings, 1 reply; 3+ messages in thread
From: Lancelot SIX @ 2022-12-06 14:52 UTC (permalink / raw)
To: Simon Marchi; +Cc: gdb-patches, Simon Marchi
Hi Simon,
The function frame_register is used outside of frame.c in the rocgdb
downstream port. Do you think we could revert this patch here?
Otherwise, this can be a change we keep downstream.
Best,
Lancelot.
On Thu, Dec 01, 2022 at 01:32:49PM -0500, Simon Marchi via Gdb-patches wrote:
> From: Simon Marchi <simon.marchi@polymtl.ca>
>
> It is only used inside frame.c.
>
> Change-Id: I44eb46a5992412f8f8b4954b2284b0ef3b549504
> ---
> gdb/frame.c | 7 ++++++-
> gdb/frame.h | 11 -----------
> 2 files changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/gdb/frame.c b/gdb/frame.c
> index c8c4ec817a42..b4079ef833e8 100644
> --- a/gdb/frame.c
> +++ b/gdb/frame.c
> @@ -1166,7 +1166,12 @@ frame_register_unwind (frame_info_ptr next_frame, int regnum,
> release_value (value);
> }
>
> -void
> +/* Get the value of the register that belongs to this FRAME. This
> + function is a wrapper to the call sequence ``frame_register_unwind
> + (get_next_frame (FRAME))''. As per frame_register_unwind(), if
> + VALUEP is NULL, the registers value is not fetched/computed. */
> +
> +static void
> frame_register (frame_info_ptr frame, int regnum,
> int *optimizedp, int *unavailablep, enum lval_type *lvalp,
> CORE_ADDR *addrp, int *realnump, gdb_byte *bufferp)
> diff --git a/gdb/frame.h b/gdb/frame.h
> index 6b841fd50636..100ab1fe48eb 100644
> --- a/gdb/frame.h
> +++ b/gdb/frame.h
> @@ -511,17 +511,6 @@ extern ULONGEST get_frame_register_unsigned (frame_info_ptr frame,
> extern bool read_frame_register_unsigned (frame_info_ptr frame,
> int regnum, ULONGEST *val);
>
> -/* Get the value of the register that belongs to this FRAME. This
> - function is a wrapper to the call sequence ``frame_register_unwind
> - (get_next_frame (FRAME))''. As per frame_register_unwind(), if
> - VALUEP is NULL, the registers value is not fetched/computed. */
> -
> -extern void frame_register (frame_info_ptr frame, int regnum,
> - int *optimizedp, int *unavailablep,
> - enum lval_type *lvalp,
> - CORE_ADDR *addrp, int *realnump,
> - gdb_byte *valuep);
> -
> /* The reverse. Store a register value relative to the specified
> frame. Note: this call makes the frame's state undefined. The
> register and frame caches must be flushed. */
> --
> 2.38.1
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [pushed] gdb: make frame_register static
2022-12-06 14:52 ` Lancelot SIX
@ 2022-12-06 15:43 ` Simon Marchi
0 siblings, 0 replies; 3+ messages in thread
From: Simon Marchi @ 2022-12-06 15:43 UTC (permalink / raw)
To: Lancelot SIX, Simon Marchi; +Cc: gdb-patches
On 12/6/22 09:52, Lancelot SIX wrote:
> Hi Simon,
>
> The function frame_register is used outside of frame.c in the rocgdb
> downstream port. Do you think we could revert this patch here?
> Otherwise, this can be a change we keep downstream.
I think it would make sense to make the function non-static in the
downstream port, and then provide a patch that makes it non-static
upstream when submitting the code that needs it outside of frame.c.
Here, I happen to be involved in this port, but that is what I would
answer to anybody else in the same situation.
Simon
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-12-06 15:44 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-01 18:32 [pushed] gdb: make frame_register static Simon Marchi
2022-12-06 14:52 ` Lancelot SIX
2022-12-06 15:43 ` Simon Marchi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).