Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: jlarmour@redhat.co.uk (Jonathan Larmour)
To: fnasser@redhat.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: thumb_skip_prologue too adventurous
Date: Fri, 24 Mar 2000 12:46:00 -0000	[thread overview]
Message-ID: <200003242046.UAA14702@murgh.cygnus.co.uk> (raw)
In-Reply-To: <38D5389B.6A481BFA@redhat.co.uk>

In article < 38D5389B.6A481BFA@redhat.co.uk > I wrote:
>Fernando Nasser wrote:
>> I am not sure if there isn't a better solution for this, but for now I
>> would say that you should check your change in as an emergency fix.
>
>I don't have checkin rights to the "src" repository, so I'd be grateful if
>you could do this for me.

I now have checkin rights. Is it therefore okay for me to check the thumb
patch in?

And add the new test below? [ left included in its entirety ]

Jifl

>>  I
>> am assuming you ran the testsuite and it did not cause any regressions,
>> right?  (I don't think it will cause any)
>
>Nope - no regressions.
> 
>> I may latter add another change to check first if there is information
>> about the prologue end in the symbol table.  I don't know why this was
>> not checked before, I just noticed it now, looking at you patch.
>
>Don't worry - it is checked, but it is done in arm_skip_prologue, before
>thumb_skip_prologue is called.
>
>> I wrote this thumb prologue scan code to match the new compiler (gcc)
>> prologue generation.  As everything is new, both Nick and I used the
>> testsuite results to verify our work. The case you mention does not have
>> a testsuite case.  I wonder if you could add a test case?
>
>I've never done a GDB testcase before, but here goes - I've attached one. It
>runs at the end of break.exp. The complication is that we need to start
>over, because the problematic programs are the ones compiled with
>optimization. So we have to jump through all the same hoops as at the start
>of the file. Some of this stuff might be overkill, but it definitely seems
>to work.
>
>I agree the addition of this test is A Good Thing as we've had these types
>of problems before on other targets with optimized code.
>
>Hope this helps. Obviously let me know if there are any problems with it.
>
>Jifl
>
>2000-03-19  Jonathan Larmour  <jlarmour@redhat.co.uk>
>
>	* gdb.base/break.exp: Add new test for setting breakpoints on
>	optimized code so we can test breakpoints work even when function
>	prologues may be optimized away
>
>
>-- 
>Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
>"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault
>-=-=-=-=-=-
>
>Index: gdb/testsuite/gdb.base/break.exp
>===================================================================
>RCS file: /cvs/src/src/gdb/testsuite/gdb.base/break.exp,v
>retrieving revision 1.2
>diff -u -5 -p -r1.2 break.exp
>--- gdb/testsuite/gdb.base/break.exp	2000/02/16 00:11:07	1.2
>+++ gdb/testsuite/gdb.base/break.exp	2000/03/19 20:26:34
>@@ -799,10 +799,83 @@ proc test_next_with_recursion {} { 
> }
> 
> test_clear_command
> test_next_with_recursion
> 
>+
>+#********
>+
>+# build a new file with optimization enabled so that we can try breakpoints
>+# on targets with optimized prologues
>+
>+set binfileo2 ${objdir}/${subdir}/${testfile}o2
>+
>+if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfileo2}" executable {debug additional_flags="-O2" }] != "" } {
>+    gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
>+}
>+
>+if [get_compiler_info ${binfileo2}] {
>+    return -1
>+}
>+
>+gdb_exit
>+gdb_start
>+gdb_reinitialize_dir $srcdir/$subdir
>+gdb_load ${binfileo2}
>+
>+if [target_info exists gdb_stub] {
>+    gdb_step_for_stub;
>+}
>+
>+#
>+# test break at function
>+#
>+gdb_test "break main" \
>+    "Breakpoint.*at.* file .*$srcfile, line.*" \
>+    "breakpoint function, optimized file"
>+
>+#
>+# test break at function
>+#
>+gdb_test "break marker4" \
>+    "Breakpoint.*at.* file .*$srcfile, line.*" \
>+    "breakpoint small function, optimized file"
>+
>+#
>+# run until the breakpoint at main is hit. For non-stubs-using targets.
>+#
>+if ![target_info exists use_gdb_stub] {
>+  if [istarget "*-*-vxworks*"] then {
>+    send_gdb "run vxmain \"2\"\n"
>+    set timeout 120
>+    verbose "Timeout is now $timeout seconds" 2
>+  } else {
>+	send_gdb "run\n"
>+  }
>+  gdb_expect {
>+    -re "The program .* has been started already.*y or n. $" {
>+	send_gdb "y\n"
>+	exp_continue
>+    }
>+    -re "Starting program.*Breakpoint \[0-9\]+,.*main .*argc.*argv.* at .*$srcfile:75.*75\[\t \]+if .argc.* \{.*$gdb_prompt $"\
>+	                    { pass "run until function breakpoint, optimized file" }
>+    -re ".*$gdb_prompt $"       { fail "run until function breakpoint, optimized file" }
>+    timeout	            { fail "run until function breakpoint, optimized file (timeout)" }
>+  }
>+} else {
>+    if ![target_info exists gdb_stub] {
>+	gdb_test continue ".*Continuing\\..*Breakpoint \[0-9\]+, main \\(argc=.*, argv=.*, envp=.*\\) at .*$srcfile:75.*75\[\t \]+if .argc.*\{.*" "stub continue, optimized file"
>+    }
>+}
>+
>+#
>+# run until the breakpoint at a small function
>+#
>+gdb_test continue "Continuing\\..*Breakpoint \[0-9\]+, marker4 \\(d=177601976\\) at .*$srcfile:51.*51\[\t \]+void.*marker4.*" \
>+			"run until breakpoint set at small function, optimized file"
>+
>+
> # Reset the default arguments for VxWorks
> if [istarget "*-*-vxworks*"] {
>     set timeout 10
>     verbose "Timeout is now $timeout seconds" 2
>     send_gdb "set args main\n"
>
>-=-=-=-=-=-



  reply	other threads:[~2000-03-24 12:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-18 14:14 Jonathan Larmour
     [not found] ` <38D40052.AF731E81@redhat.co.uk>
     [not found]   ` <38D5064B.40AE9470@redhat.com>
2000-03-19 12:29     ` Jonathan Larmour
2000-03-24 12:46       ` Jonathan Larmour [this message]
2000-04-01  0:00 ` Jonathan Larmour

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=200003242046.UAA14702@murgh.cygnus.co.uk \
    --to=jlarmour@redhat.co.uk \
    --cc=fnasser@redhat.com \
    --cc=gdb-patches@sourceware.cygnus.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