Re: [PING^2][PATCH] in_plt_section: support alternate stub section names

Pedro Alves
2013-06-20T16:45:44Z

On 06/20/2013 05:19 PM, Maciej W. Rozycki wrote:

>
> return 0;
> Index: gdb-fsf-trunk-quilt/gdb/mips-tdep.c
> ===================================================================
> --- gdb-fsf-trunk-quilt.orig/gdb/mips-tdep.c 2013-06-19 16:54:49.000000000 +0100
> +++ gdb-fsf-trunk-quilt/gdb/mips-tdep.c 2013-06-19 16:55:00.280199593 +0100
> @@ -3628,12 +3628,7 @@ mips_stub_frame_sniffer (const struct fr
> if (in_plt_section (pc, NULL))
> return 1;
>
> - /* Binutils for MIPS puts lazy resolution stubs into .MIPS.stubs. */
> - s = find_pc_section (pc);
> -
> - if (s != NULL
> - && strcmp (bfd_get_section_name (s->objfile->obfd, s->the_bfd_section),
> - ".MIPS.stubs") == 0)
> + if (in_plt_section (pc, ".MIPS.stubs"))
> return 1;

Quite honestly, this looks like an odd API to me. If all
MIPS callers will have to pass in ".MIPS.stubs", then it just
looks like in_plt_section becomes a convenience for "is
pc in section.

It'd make more sense to me to refactor in_plt_section to
something like this, somewhere:

int
pc_in_section (CORE_ADDR pc, const char *name)
{
struct obj_section *s;
int retval = 0;

s = find_pc_section (pc);

retval = (s != NULL
&& s->the_bfd_section->name != NULL
&& strcmp (s->the_bfd_section->name, name) == 0);
return (retval);
}

And then:

/* In SVR4, we recognize a trampoline by it's section name.
That is, if the pc is in a section named ".plt" then we are in
a trampoline. */

int
in_plt_section (CORE_ADDR pc)
{
return pc_in_section (pc, ".plt");
}

And then MIPS would have somewhere, mips-tdep.c perhaps,
something like:

int
in_mips_stubs_section (CORE_ADDR pc)
{
return pc_in_section (pc, ".MIPS.stubs");
}

Or

#define MIPS_STUBS_SECTION ".MIPS.stubs"
pc_in_section (pc, MIPS_STUBS_SECTION);

As bonus, you end up with just one place that
can typo the section name.

Perhaps missed the plan to make in_plt_section fetch the
section name from elsewhere, instead of taking it as argument,
so callers in common code don't care?

--
Pedro Alves