[v2,10/14] make dwarf_expr_frame_base_1 public
Commit Message
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
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
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
> 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.
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
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.
@@ -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)
{
@@ -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. */