diff mbox

[v2,10/14] make dwarf_expr_frame_base_1 public

Message ID 1403279874-23781-11-git-send-email-tromey@redhat.com
State New
Headers show

Commit Message

Tom Tromey June 20, 2014, 3:57 p.m. UTC 
This exports dwarf_expr_frame_base_1 so that other code can use it.

2014-06-20  Tom Tromey  <tromey@redhat.com>

	* dwarf2loc.h (dwarf_expr_frame_base_1): Declare.
	* dwarf2loc.c (dwarf_expr_frame_base_1): Now public.
---
 gdb/ChangeLog   |  5 +++++
 gdb/dwarf2loc.c |  7 +++----
 gdb/dwarf2loc.h | 10 ++++++++++
 3 files changed, 18 insertions(+), 4 deletions(-)

Comments

Doug Evans June 20, 2014, 8:05 p.m. UTC | #1 
On Jun 20, 2014 6:33 PM, "Tom Tromey" <tromey@redhat.com> wrote:
>
> This exports dwarf_expr_frame_base_1 so that other code can use it.
>
> 2014-06-20  Tom Tromey  <tromey@redhat.com>
>
>         * dwarf2loc.h (dwarf_expr_frame_base_1): Declare.
>         * dwarf2loc.c (dwarf_expr_frame_base_1): Now public.

[apologies for the repeat ... curse you gmail ...]

Hi.
Can you remove the _1?
(renaming it as needed)
I see the non _1 version is also static, so some reasonable renaming
(perhaps of both) should be simple enough.

TIA
Gary Benson June 23, 2014, 8:18 a.m. UTC | #2 
Doug Evans wrote:
> On Jun 20, 2014 6:33 PM, "Tom Tromey" <tromey@redhat.com> wrote:
> >
> > This exports dwarf_expr_frame_base_1 so that other code can use it.
> >
> > 2014-06-20  Tom Tromey  <tromey@redhat.com>
> >
> >         * dwarf2loc.h (dwarf_expr_frame_base_1): Declare.
> >         * dwarf2loc.c (dwarf_expr_frame_base_1): Now public.
> 
> [apologies for the repeat ... curse you gmail ...]
> 
> Can you remove the _1?
> (renaming it as needed)
> I see the non _1 version is also static, so some reasonable renaming
> (perhaps of both) should be simple enough.

Is there some convention about what "_1" means in a function name?

Cheers,
Gary
Eli Zaretskii June 23, 2014, 2:57 p.m. UTC | #3 
> Date: Mon, 23 Jun 2014 09:18:15 +0100
> From: Gary Benson <gbenson@redhat.com>
> Cc: Tom Tromey <tromey@redhat.com>, gdb-patches <gdb-patches@sourceware.org>
> 
> > > 2014-06-20  Tom Tromey  <tromey@redhat.com>
> > >
> > >         * dwarf2loc.h (dwarf_expr_frame_base_1): Declare.
> > >         * dwarf2loc.c (dwarf_expr_frame_base_1): Now public.
> > 
> > [apologies for the repeat ... curse you gmail ...]
> > 
> > Can you remove the _1?
> > (renaming it as needed)
> > I see the non _1 version is also static, so some reasonable renaming
> > (perhaps of both) should be simple enough.
> 
> Is there some convention about what "_1" means in a function name?

In most, if not all, cases I saw those are internal subroutines of the
sans-_1 peers.
Gary Benson June 24, 2014, 10:18 a.m. UTC | #4 
Eli Zaretskii wrote:
> > Date: Mon, 23 Jun 2014 09:18:15 +0100
> > From: Gary Benson <gbenson@redhat.com>
> > Cc: Tom Tromey <tromey@redhat.com>, gdb-patches <gdb-patches@sourceware.org>
> > 
> > > > 2014-06-20  Tom Tromey  <tromey@redhat.com>
> > > >
> > > >         * dwarf2loc.h (dwarf_expr_frame_base_1): Declare.
> > > >         * dwarf2loc.c (dwarf_expr_frame_base_1): Now public.
> > > 
> > > [apologies for the repeat ... curse you gmail ...]
> > > 
> > > Can you remove the _1?
> > > (renaming it as needed)
> > > I see the non _1 version is also static, so some reasonable renaming
> > > (perhaps of both) should be simple enough.
> > 
> > Is there some convention about what "_1" means in a function name?
> 
> In most, if not all, cases I saw those are internal subroutines of the
> sans-_1 peers.

Is "_1" acceptable in new code?  I have a vague memory of having to
update a patch to rename a new "_1" function I'd created.  If it's
not then maybe these should be renamed as people touch them.

In any event, I don't think any non-static function should be called
"_1".

Thanks,
Gary
Pedro Alves June 24, 2014, 1:03 p.m. UTC | #5 
On 06/24/2014 11:18 AM, Gary Benson wrote:
> Eli Zaretskii wrote:
>>> Date: Mon, 23 Jun 2014 09:18:15 +0100
>>> From: Gary Benson <gbenson@redhat.com>

>>> Is there some convention about what "_1" means in a function name?
>>
>> In most, if not all, cases I saw those are internal subroutines of the
>> sans-_1 peers.
> 
> Is "_1" acceptable in new code?  I have a vague memory of having to
> update a patch to rename a new "_1" function I'd created.  If it's
> not then maybe these should be renamed as people touch them.

I think it's fine in the situation Eli mentions.  I'm just now
looking at a patch from Markus that adds one, exactly as an internal
helper, for instance.

> In any event, I don't think any non-static function should be called
> "_1".

Yeah, ideally when exporting a function we come up with a clearer name.
diff mbox

Patch

diff --git a/gdb/dwarf2loc.c b/gdb/dwarf2loc.c
index 4275864..db3ee7d 100644
--- a/gdb/dwarf2loc.c
+++ b/gdb/dwarf2loc.c
@@ -44,9 +44,6 @@ 
 
 extern int dwarf2_always_disassemble;
 
-static void dwarf_expr_frame_base_1 (struct symbol *framefunc, CORE_ADDR pc,
-				     const gdb_byte **start, size_t *length);
-
 static const struct dwarf_expr_context_funcs dwarf_expr_ctx_funcs;
 
 static struct value *dwarf2_evaluate_loc_desc_full (struct type *type,
@@ -414,7 +411,9 @@  const struct symbol_block_ops dwarf2_block_frame_base_loclist_funcs =
   loclist_find_frame_base_location
 };
 
-static void
+/* See dwarf2loc.h.  */
+
+void
 dwarf_expr_frame_base_1 (struct symbol *framefunc, CORE_ADDR pc,
 			 const gdb_byte **start, size_t *length)
 {
diff --git a/gdb/dwarf2loc.h b/gdb/dwarf2loc.h
index 8ad5fa9..341f64d 100644
--- a/gdb/dwarf2loc.h
+++ b/gdb/dwarf2loc.h
@@ -80,6 +80,16 @@  extern const gdb_byte *dwarf2_fetch_constant_bytes (sect_offset,
 struct type *dwarf2_get_die_type (cu_offset die_offset,
 				  struct dwarf2_per_cu_data *per_cu);
 
+/* Find the frame base information for FRAMEFUNC at PC.  START is an
+   out parameter which is set to point to the DWARF expression to
+   compute.  LENGTH is an out parameter which is set to the length of
+   the DWARF expression.  This throws an exception on error or if an
+   expression is not found; the returned length will never be
+   zero.  */
+
+extern void dwarf_expr_frame_base_1 (struct symbol *framefunc, CORE_ADDR pc,
+				     const gdb_byte **start, size_t *length);
+
 /* Evaluate a location description, starting at DATA and with length
    SIZE, to find the current location of variable of TYPE in the context
    of FRAME.  */