Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: guitton@adacore.com
Cc: gdb-patches@sourceware.org, guitton@adacore.com
Subject: Re: [RFA] Support for x86 on-stack trampolines
Date: Wed, 04 May 2011 10:20:00 -0000	[thread overview]
Message-ID: <201105041020.p44AKGt2025840@glazunov.sibelius.xs4all.nl> (raw)
In-Reply-To: <1304468424-2060-1-git-send-email-guitton@adacore.com> (message	from Jerome Guitton on Wed, 4 May 2011 02:20:24 +0200)

> From: Jerome Guitton <guitton@adacore.com>
> Date: Wed,  4 May 2011 02:20:24 +0200
> 
> On x86 cross targets, the debugger has trouble stepping over the following
> line of Ada code (initialization of a class-wide object):
> 
>     S: Shape'Class := R;
> 
> Here is what happens:
>    (gdb) n
>    0x60c49e8a in ?? ()
> 
> The program jumps to this code location, which is a trampoline
> located on the stack (there is an implicit call to a routine internally
> generated by the Ada expander). As it is on the stack, GDB is naturally
> unable to find the bounds of the current function, or any debugging
> information, and is thus unable to continue.
> 
> This patch adds support for this sort of trampoline. It re-uses some
> code from prologue scan (insn pattern matching). Tested on x86-linux,
> no new regression. OK to apply?

Hmm, I think the new name for i386_match_insn is confusing.  Also, it
isn't really necessary to change its prototype.  It returns a pointer
to the matched pattern, so some trivial pointer arithmetic will give
you the index into the array of patterns.

Some further comments inline below.

> +/* Stack-based trampolines.  */
> +
> +/* These trampolines are used on cross x86 targets, when taking the
> +   address of a nested function.  When executing these trampolines,
> +   no stack frame is set up, so we are in a similar situation as in
> +   epilogues and i386_epilogue_frame_this_id can be re-used.
> +*/

That final */ should be on the previous line.

> +
> +/* Static chain passed in register */

Missing full stop at the end of the comment.

> +
> +struct i386_insn i386_tramp_chain_in_reg_insns[] =
> +{
> +  /* mov   <imm>, %ecx (or %eax, in case of fastcall) */
> +  {5, {0xb8}, {0xfe}},
> +
> +  /* jmp   <imm> */
> +  {5, {0xe9}, {0xff}},
> +
> +  {0}
> +};
> +
> +/* Static chain passed on stack (when regparm=3) */

Same here.

> +
> +struct i386_insn i386_tramp_chain_on_stack_insns[] =
> +{
> +  /* push   <imm> */
> +  {5, {0x68}, {0xff}},
> +
> +  /* jmp   <imm> */
> +  {5, {0xe9}, {0xff}},
> +
> +  {0}
> +};

Could you use the same style for these as the existing instruction
patterns (both for the way you describe the instructions in the
comments and the spacing for the actual data)?

> +
> +/* Return whether PC points inside a stack trampoline.   */
> +
> +static int
> +i386_in_stack_tramp_p (struct gdbarch *gdbarch, CORE_ADDR pc)
> +{
> +  gdb_byte insn;
> +  char *name;
> +
> +  if (target_read_memory (pc, &insn, 1))
> +    return 0;
> +
> +  /* A stack trampoline is detected if no name is associated
> +    to the current pc and if it points inside a trampoline
> +    sequence.  */
> +
> +  if (!i386_match_insn_block (pc, i386_tramp_chain_in_reg_insns)
> +      && !i386_match_insn_block (pc, i386_tramp_chain_on_stack_insns))
> +    return 0;
> +
> +  find_pc_partial_function (pc, &name, NULL, NULL);
> +  return !name;
> +}

Is checking the instructions before checking the name the most
efficient way of doing this?

> +
> +static int
> +i386_stack_tramp_frame_sniffer (const struct frame_unwind *self,
> +			     struct frame_info *this_frame,
> +			     void **this_prologue_cache)
> +{
> +  if (frame_relative_level (this_frame) == 0)
> +    return i386_in_stack_tramp_p (get_frame_arch (this_frame),
> +				  get_frame_pc (this_frame));
> +  else
> +    return 0;
> +}
> +
> +static const struct frame_unwind i386_stack_tramp_frame_unwind =
> +{
> +  NORMAL_FRAME,
> +  default_frame_unwind_stop_reason,
> +  i386_epilogue_frame_this_id,
> +  i386_frame_prev_register,
> +  NULL, 
> +  i386_stack_tramp_frame_sniffer
> +};
> +\f
> +
>  /* Signal trampolines.  */
>  
>  static struct i386_frame_cache *
> @@ -7295,6 +7425,7 @@ i386_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
>      tdep->mm0_regnum = -1;
>  
>    /* Hook in the legacy prologue-based unwinders last (fallback).  */
> +  frame_unwind_append_unwinder (gdbarch, &i386_stack_tramp_frame_unwind);
>    frame_unwind_append_unwinder (gdbarch, &i386_sigtramp_frame_unwind);
>    frame_unwind_append_unwinder (gdbarch, &i386_frame_unwind);


  parent reply	other threads:[~2011-05-04 10:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-04  0:21 Jerome Guitton
2011-05-04  8:55 ` Pedro Alves
2011-05-04 14:52   ` Jerome Guitton
2011-05-04 10:20 ` Mark Kettenis [this message]
2011-05-04 15:17   ` Jerome Guitton
2011-05-04 15:31     ` Mark Kettenis
2011-05-05 15:10       ` Jerome Guitton
2011-05-05 15:18         ` Mark Kettenis
2011-05-05 16:03           ` Jerome Guitton

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=201105041020.p44AKGt2025840@glazunov.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=gdb-patches@sourceware.org \
    --cc=guitton@adacore.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