From: Daniel Jacobowitz <drow@false.org>
To: PAUL GILLIAM <pgilliam@us.ibm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] "single step" atomic instruction sequences as a whole.
Date: Fri, 10 Nov 2006 21:18:00 -0000 [thread overview]
Message-ID: <20061110211819.GE1115@nevyn.them.org> (raw)
In-Reply-To: <1151005894.7608.63.camel@dufur.beaverton.ibm.com>
On Thu, Jun 22, 2006 at 12:51:34PM -0700, PAUL GILLIAM wrote:
> This fixes a problem noticed on ppc64-linux: automatically stepping out
> of the 'puts' library function (because it had no line number
> information) would cause an endless loop. This happened because of the
> following sequence of instructions:
>
> L1: lwarx r11,0,r3
> cmpw r11,r9
> bne- L2
> stwcx. r0,0,r3
> bne- L1
> L2: isync
Since no one else did I guess I get to look at these :-)
Paul, do you know if these patches still work? There's a report that
they cause internal errors. One great way to test would be adding a
testcase to gdb.arch, and also running the GDB testsuite. I imagine
this is caused by single stepping over anything _but_ an atomic op,
since insert_single_step_breakpoint was called conditionally and
remove_single_step_breakpoints unconditionally. I imagine we got there
because you always return 1, even if you didn't do anything.
I'm still not thrilled with the approach but no one came up with an
alternative so we'll do it your way - implemented is better than not.
> I have attached two patches. 'change-software-single-step.diff' makes
> the generic changes to all the existing software single step routines:
> changing their type from void to int and always returning a 1.
Two things. First of all, the patch won't compile; I saw at least one
"return 1" without a semicolon. Secondly, here's some suggestions for
the ChangeLog:
> * gdbarch.sh: Change the return type of software_single_step from
> void to int and reformatted some comments to <= 80 columns.
> * gdbarch.c, gdbarch.h: Regenerated.
> * alpha-tdep.c (alpha_software_single_step): Change the return type
> from void to int and always return 1.
> * alpha-tdep.h: Change the return type of alpha_software_single_step
> from void to int.
* gdbarch.sh (software_single_step): Return int. Doc fixes.
* gdbarch.c, gdbarch.h: Regenerated.
* alpha-tdep.c (alpha_software_single_step): Return 1.
* alpha-tdep.h (alpha_software_single_step): Update.
Or, for big mechanical changes like this one, I think it's reasonable
to summarize:
* alpha-tdep.c, alpha-tdep.h, arm-tdep.c, [list all the
files]: Update software_single_step methods.
> 'ppc-atomic-single-step.diff' adds the new ppc_atomic_single_step
> routine to ppc-linux-tdep.c and updates the ppc_linux_init_abi routine
> to use set_gdbarch_software_single_step() to plug the new routine into
> the architecture vector.
> + /* Enable software_single_step in case someone tries to sngle step a
> + sequence of instructions that should be atomic. */
Two spaces after a period.
> + for (i= 1; i < 5; ++i)
Spaces around an operator.
> + error (_("Tried to step over an atomic sequence of instructions but could not find the end of the sequence."));
Line too long. Either wrap the string or add newlines to the error
message, for instance:
error (_("Tried to step over an atomic sequence of instructions but "
"could not find the end of the sequence."));
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2006-11-10 21:18 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-22 20:56 PAUL GILLIAM
2006-06-22 21:53 ` PAUL GILLIAM
2006-06-22 22:20 ` PAUL GILLIAM
2006-11-10 21:18 ` Daniel Jacobowitz [this message]
2006-09-18 11:59 emin ak
2006-11-09 13:07 ` [patch] " emin ak
2007-02-06 11:02 Luis Machado
2007-02-06 12:11 ` Emi SUZUKI
2007-02-07 13:10 ` Luis Machado
2007-02-08 13:00 ` Emi SUZUKI
2007-02-17 2:24 Luis Machado
2007-02-27 13:00 ` Emi SUZUKI
2007-02-27 13:17 ` Daniel Jacobowitz
2007-02-28 8:08 ` Emi SUZUKI
2007-02-28 11:46 ` Daniel Jacobowitz
2007-02-28 16:09 ` Luis Machado
2007-03-02 12:47 ` Emi SUZUKI
2007-03-06 11:00 ` Andreas Schwab
2007-03-06 12:24 ` Daniel Jacobowitz
2007-03-08 8:50 ` Emi SUZUKI
2007-03-08 16:15 ` Ulrich Weigand
2007-03-13 6:12 ` SUZUKI Emi
2007-03-15 22:24 Luis Machado
2007-04-10 20:40 ` Daniel Jacobowitz
2007-04-12 12:09 ` Luis Machado
2007-04-12 12:15 ` Daniel Jacobowitz
2007-04-12 12:54 ` Luis Machado
2007-04-12 12:58 ` Daniel Jacobowitz
2007-04-12 13:30 ` Luis Machado
2007-04-12 13:35 ` Daniel Jacobowitz
2007-04-12 14:58 ` Ulrich Weigand
2007-04-12 15:33 ` Daniel Jacobowitz
2007-04-12 17:16 ` Ulrich Weigand
2007-04-12 18:25 ` Daniel Jacobowitz
2007-04-12 20:09 ` Ulrich Weigand
2007-04-12 20:16 ` Mark Kettenis
2007-04-12 20:43 ` Ulrich Weigand
2007-04-14 15:20 ` Mark Kettenis
2007-04-14 18:13 ` Ulrich Weigand
2007-04-12 20:49 ` Daniel Jacobowitz
2007-04-12 20:48 ` Daniel Jacobowitz
2007-04-12 14:32 ` Ulrich Weigand
2007-04-12 14:47 ` Luis Machado
2007-04-12 15:00 ` Ulrich Weigand
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=20061110211819.GE1115@nevyn.them.org \
--to=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=pgilliam@us.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