Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] workaround gcc46: prologue skip skips too far (PR 12435) #2
Date: Thu, 08 Sep 2011 17:31:00 -0000	[thread overview]
Message-ID: <CADPb22R1Ya6jKj76em=OvAQXU7n=TZ-2eqVzu5upzR0KY-WV2Q@mail.gmail.com> (raw)
In-Reply-To: <20110722215821.GA3433@host1.jankratochvil.net>

On Fri, Jul 22, 2011 at 2:58 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> Hi,
>
> this is an improved patch of a former:
>        [patch] workaround gcc46: prologue skip skips too far (PR 12435)
>        http://sourceware.org/ml/gdb-patches/2011-03/msg01108.html
>        cancel/FYI: Re: [patch] workaround gcc46: prologue skip skips too far (PR 12435)
>        http://sourceware.org/ml/gdb-patches/2011-03/msg01123.html
>
> [...]
>
> I will update the code after FSF gcc gets fixed to minimize the workaround.

I realize this is checked in, but a couple of comments for maybe the
next patch for this.

> [...]
>
> --- a/gdb/amd64-tdep.c
> +++ b/gdb/amd64-tdep.c
> @@ -1902,6 +1902,9 @@ amd64_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR start_pc)
>  {
>   struct amd64_frame_cache cache;
>   CORE_ADDR pc;
> +  struct symtab_and_line start_pc_sal, next_sal;
> +  gdb_byte buf[4 + 8 * 7];
> +  int offset, xmmreg;
>
>   amd64_init_frame_cache (&cache);
>   pc = amd64_analyze_prologue (gdbarch, start_pc, 0xffffffffffffffffLL,
> @@ -1909,7 +1912,71 @@ amd64_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR start_pc)
>   if (cache.frameless_p)
>     return start_pc;
>
> -  return pc;
> +  /* GCC PR debug/48827 produced false prologue end:
> +     84 c0                test   %al,%al
> +     74 23                je     after
> +     <-- here is 0 lines advance - the false prologue end marker.
> +     0f 29 85 70 ff ff ff movaps %xmm0,-0x90(%rbp)
> +     0f 29 4d 80          movaps %xmm1,-0x80(%rbp)
> +     0f 29 55 90          movaps %xmm2,-0x70(%rbp)
> +     0f 29 5d a0          movaps %xmm3,-0x60(%rbp)
> +     0f 29 65 b0          movaps %xmm4,-0x50(%rbp)
> +     0f 29 6d c0          movaps %xmm5,-0x40(%rbp)
> +     0f 29 75 d0          movaps %xmm6,-0x30(%rbp)
> +     0f 29 7d e0          movaps %xmm7,-0x20(%rbp)
> +     after:  */
> +
> +  if (pc == start_pc)
> +    return pc;
> +
> +  start_pc_sal = find_pc_sect_line (start_pc, NULL, 0);
> +  if (start_pc_sal.symtab == NULL
> +      || !start_pc_sal.symtab->amd64_prologue_line_bug
> +      || start_pc_sal.pc != start_pc || pc >= start_pc_sal.end)
> +    return pc;
> +
> +  next_sal = find_pc_sect_line (start_pc_sal.end, NULL, 0);
> +  if (next_sal.line != start_pc_sal.line)
> +    return pc;
> +
> +  /* START_PC can be from overlayed memory, ignored here.  */
> +  if (target_read_memory (next_sal.pc - 4, buf, sizeof (buf)) != 0)
> +    return pc;
> +
> +  /* test %al,%al */
> +  if (buf[0] != 0x84 || buf[1] != 0xc0)
> +    return pc;
> +  /* je AFTER */
> +  if (buf[2] != 0x74)
> +    return pc;
> +
> +  offset = 4;
> +  for (xmmreg = 0; xmmreg < 8; xmmreg++)
> +    {
> +      /* movaps %xmmreg?,-0x??(%rbp) */
> +      if (buf[offset] != 0x0f || buf[offset + 1] != 0x29
> +          || (buf[offset + 2] & 0b00111111) != (xmmreg << 3 | 0b101))
> +       return pc;
> +
> +      if ((buf[offset + 2] & 0b11000000) == 0b01000000)
> +       {
> +         /* 8-bit displacement.  */
> +         offset += 4;
> +       }
> +      else if ((buf[offset + 2] & 0b11000000) == 0b10000000)
> +       {
> +         /* 32-bit displacement.  */
> +         offset += 7;
> +       }
> +      else
> +       return pc;
> +    }
> +
> +  /* je AFTER */
> +  if (offset - 4 != buf[3])
> +    return pc;
> +
> +  return next_sal.end;
>  }

These kinds of functions tend to grow and grow and become hard to maintain.
IWBN if all this new code is about a specific issue then tuck it away
in its own function.
[Or at least document both the start and end of it.]

> [...]
>
> --- a/gdb/symtab.h
> +++ b/gdb/symtab.h
> @@ -784,6 +784,11 @@ struct symtab
>
>   unsigned int epilogue_unwind_valid : 1;
>
> +  /* At least GCC 4.6.0 and 4.6.1 can produce invalid false prologue and marker
> +     on amd64.  This flag is set independently of the symtab arch.  */
> +
> +  unsigned amd64_prologue_line_bug : 1;
> +
>   /* The macro table for this symtab.  Like the blockvector, this
>      may be shared between different symtabs --- and normally is for
>      all the symtabs in a given compilation unit.  */

I can hear the screams of pushback if a random net person wanted to
check in anything architecture specific to the architecture
independent part of gdb. :-)


  parent reply	other threads:[~2011-09-08 17:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-22 23:04 Jan Kratochvil
2011-07-24 18:16 ` Mark Kettenis
2011-07-24 20:00   ` Jan Kratochvil
2011-09-08 15:54 ` Jan Kratochvil
2011-09-08 17:31 ` Doug Evans [this message]
2011-09-08 19:13   ` Jan Kratochvil
2011-09-09 19:52     ` Jan Kratochvil
2011-09-12 17:23       ` Doug Evans

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='CADPb22R1Ya6jKj76em=OvAQXU7n=TZ-2eqVzu5upzR0KY-WV2Q@mail.gmail.com' \
    --to=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.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