Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>, gdb-patches@sourceware.org
Subject: Re: Regression on PowerPC (Re: [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #3)
Date: Tue, 03 Jan 2012 15:52:00 -0000	[thread overview]
Message-ID: <20120103155206.GM2730@adacore.com> (raw)
In-Reply-To: <201201031444.q03Eir77009359@d06av02.portsmouth.uk.ibm.com>

> > Checked in:
> > 	http://sourceware.org/ml/gdb-cvs/2012-01/msg00013.html
> > Checked in 7.4:
> > 	http://sourceware.org/ml/gdb-cvs/2012-01/msg00014.html

ARGH! Thanks for letting us know.

> Switching to the ON_STACK method fixes this for me.  But I'm not sure
> if there are other platforms beside PowerPC that have the same problem ...
> Maybe we ought to default to ON_STACK (at least on Linux?)?

But this wouldn't prevent the same sort of problem on other
platforms. I think we don't know enough to keep this change in
as is.

It seems to me, at this point, that indeed the best way to solve
the original problem is to transition the GNU/Linux platforms to
ON_STACK. We then no longer need the patch that causes the regression.

> Note that it's a bit annoying that we need to provide a push_dummy_code
> routine in order to be able to use ON_STACK.  Maybe there should be a
> default implementation based on gdbarch_inner_than/gdbarch_frame_align_p
> and the breakpoint length?

Agreed. We actually used to have such as routine, and deleted it
a while ago, after the last caller got removed. I reposted it
when I sent the patch series to add support for VxWorks.

The removal:
http://www.sourceware.org/ml/gdb-patches/2008-09/msg00320.html

The code:

> static CORE_ADDR
> rs6000_vxworks_push_dummy_code (struct gdbarch *gdbarch,
>                                 CORE_ADDR sp, CORE_ADDR funaddr,
>                                 struct value **args, int nargs,
>                                 struct type *value_type,
>                                 CORE_ADDR *real_pc, CORE_ADDR *bp_addr,
>                                 struct regcache *regcache)
> {
>   /* Something here to findout the size of a breakpoint and then
>      allocate space for it on the stack.  */
>   int bplen;
>   /* This code assumes frame align.  */
>   gdb_assert (gdbarch_frame_align_p (gdbarch));
>   /* Force the stack's alignment.  The intent is to ensure that the SP
>      is aligned to at least a breakpoint instruction's boundary.  */
>   sp = gdbarch_frame_align (gdbarch, sp);
>   /* Allocate space for, and then position the breakpoint on the stack.  */
>   if (gdbarch_inner_than (gdbarch, 1, 2))
>     {
>       CORE_ADDR bppc = sp;
>       gdbarch_breakpoint_from_pc (gdbarch, &bppc, &bplen);
>       sp = gdbarch_frame_align (gdbarch, sp - bplen);
>       (*bp_addr) = sp;
>       /* Should the breakpoint size/location be re-computed here?  */
>     }
>   else
>     {
>       (*bp_addr) = sp;
>       gdbarch_breakpoint_from_pc (gdbarch, bp_addr, &bplen);
>       sp = gdbarch_frame_align (gdbarch, sp + bplen);
>     }
>   /* Inferior resumes at the function entry point.  */
>   (*real_pc) = funaddr;
>   return sp;
> }

-- 
Joel


  reply	other threads:[~2012-01-03 15:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-22 20:49 [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 Jan Kratochvil
2011-12-27  6:23 ` Joel Brobecker
2011-12-28 16:30   ` Jan Kratochvil
2011-12-28 18:47     ` [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #2 Jan Kratochvil
2011-12-28 20:40       ` Mark Kettenis
2011-12-30  2:45         ` [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #3 Jan Kratochvil
2011-12-30  8:46           ` Joel Brobecker
2011-12-30 11:11             ` Mark Kettenis
2011-12-30 14:16               ` Jan Kratochvil
2011-12-31  2:56               ` Peter Schauer
2011-12-30 11:25             ` Jan Kratochvil
2012-01-01 22:22               ` Jan Kratochvil
2012-01-02  2:45                 ` Joel Brobecker
2012-01-02  2:58                   ` Jan Kratochvil
2012-01-03 14:45                     ` Regression on PowerPC (Re: [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #3) Ulrich Weigand
2012-01-03 15:52                       ` Joel Brobecker [this message]
2012-01-04 14:01                       ` [revert] " Jan Kratochvil
2012-01-04 14:09                         ` Joel Brobecker
2012-03-08 23:24                         ` [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #4 [Re: [revert] Regression on PowerPC] Jan Kratochvil
2012-03-09  7:22                           ` cancel: " Jan Kratochvil
2012-01-02 14:10 ` [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 Pedro Alves
2012-01-02 14:20   ` Jan Kratochvil
2012-01-02 14:44     ` Pedro Alves
2012-01-02 14:53       ` Jan Kratochvil

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=20120103155206.GM2730@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=uweigand@de.ibm.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