From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Subject: Re: [PATCH] [SH] Prologue skipping if there is none
Date: Thu, 01 Mar 2012 00:13:00 -0000 [thread overview]
Message-ID: <20120229171247.12db9412@mesquite.lan> (raw)
In-Reply-To: <87r4xd528y.fsf@schwinge.name>
On Wed, 29 Feb 2012 12:05:01 +0100
Thomas Schwinge <thomas@schwinge.name> wrote:
> As we already had figured out, it introduces the following nine
> regressions (PASS -> FAIL):
>
> FAIL: gdb.base/store.exp: continue to add_charest
> FAIL: gdb.base/store.exp: continue to add_short
> FAIL: gdb.base/store.exp: continue to add_int
> FAIL: gdb.base/store.exp: continue to add_long
> FAIL: gdb.base/store.exp: continue to add_longest
> FAIL: gdb.base/structs.exp: advance to fun<n> for return; return 2 structs-td-tf
> FAIL: gdb.base/structs.exp: advance to fun<n> for finish; return 2 structs-td-tf
> FAIL: gdb.base/structs.exp: advance to fun<n> for return; return 2 structs-tf-td
> FAIL: gdb.base/structs.exp: advance to fun<n> for finish; return 2 structs-tf-td
I could live with these if there were a significant number of progressions
elsewhere.
> As already reported, an additional regression for sh-linux-gnu:
>
> Running /scratch/tschwing/FM_sh-linux-gnu/src/gdb-mainline/gdb/testsuite/gdb.threads/staticthreads.exp ...
> PASS: gdb.threads/staticthreads.exp: successfully compiled posix threads test case
> PASS: gdb.threads/staticthreads.exp: set print sevenbit-strings
> PASS: gdb.threads/staticthreads.exp: break sem_post
> -PASS: gdb.threads/staticthreads.exp: Continue to main's call of sem_post
> +FAIL: gdb.threads/staticthreads.exp: Continue to main's call of sem_post (the program exited)
> PASS: gdb.threads/staticthreads.exp: rerun to main
> PASS: gdb.threads/staticthreads.exp: handle SIG32 nostop noprint pass
> -PASS: gdb.threads/staticthreads.exp: handle SIG32 helps
> -PASS: gdb.threads/staticthreads.exp: info threads
> +FAIL: gdb.threads/staticthreads.exp: handle SIG32 helps (the program exited)
> +KFAIL: gdb.threads/staticthreads.exp: info threads (PRMS: gdb/1328)
> PASS: gdb.threads/staticthreads.exp: GDB exits with static thread program
>
> The breakpoint for sem_post is mis-calculated to be somewhere near the
> end of the function (after the epilogue, even).
This is bad. I think this could be fixed (by stopping the scan if a
return instruction is seen), but I'm not sure it's worth it at the
moment.
> And, as already reported, there is this progression for sh-linux-gnu:
>
> -FAIL: gdb.base/gdb1250.exp: setting breakpoint at abort
> +PASS: gdb.base/gdb1250.exp: backtrace from abort
>
> The PLT stub for abort happens to be the last one in the .plt section,
> and (I suppose) your more advanced limit_pc/func_end mechanism (instead
> of hard-coding 28 instructions) helps to avoid hitting the
> end-of-.plt-section border. (The question is whether it really makes
> sense to go looking for a prologue in a PLT stub, but that's what GDB is
> currently doing, and it should be without harm.)
>
> As for the other advancements that you reported, do you have any
> additional patches in your tree; see the questions in my 2012-02-21
> email, Message-ID: <8762f09stp.fsf@schwinge.name>.
It turns out that I do. It's unrelated to prologue analysis. I'll
post it separately in a few minutes. (I'll CC you on it.)
It's a small patch that I thought I had removed from my tree. Sorry
about the noise caused by that patch.
> I'll now try to carry over your ``more advanced limit_pc/func_end
> mechanism'' separately.
I wouldn't make it a high priority. Your patch provides very good
results and my additions (on the prologue analysis front) hurt more
than they help.
Thanks for all of your work on this matter.
Kevin
next prev parent reply other threads:[~2012-03-01 0:13 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-15 14:00 Thomas Schwinge
2012-02-15 14:54 ` Pedro Alves
2012-02-16 15:27 ` [PATCH] [SH] GDB crash in sh_is_renesas_calling_convention, TYPE_CALLING_CONVENTION (was: Prologue skipping if there is none) Thomas Schwinge
2012-02-16 19:38 ` [PATCH] [SH] GDB crash in sh_is_renesas_calling_convention, TYPE_CALLING_CONVENTION Tom Tromey
2012-02-15 16:09 ` [PATCH] [SH] Prologue skipping if there is none Kevin Buettner
2012-02-16 0:13 ` Kevin Buettner
2012-02-16 16:59 ` Thomas Schwinge
2012-02-17 2:30 ` Kevin Buettner
2012-02-20 16:19 ` Thomas Schwinge
2012-02-21 5:25 ` Kevin Buettner
2012-02-24 11:09 ` Thomas Schwinge
2012-02-24 22:21 ` Kevin Buettner
2012-02-29 13:51 ` Thomas Schwinge
2012-03-01 0:13 ` Kevin Buettner [this message]
2012-03-01 9:03 ` Thomas Schwinge
2012-03-01 9:00 ` Thomas Schwinge
2012-03-02 0:19 ` Kevin Buettner
2012-03-02 11:18 ` Thomas Schwinge
2012-03-02 12:01 ` Pedro Alves
2012-03-02 14:15 ` Thomas Schwinge
2012-03-06 19:08 ` Pedro Alves
2012-03-03 1:18 ` Kevin Buettner
2012-03-05 15:16 ` Thomas Schwinge
2012-03-05 19:40 ` Kevin Buettner
2012-02-21 15:23 ` Thomas Schwinge
2012-02-22 14:54 ` Simulator testing for sh and sh64 (was: [PATCH] [SH] Prologue skipping if there is none) Thomas Schwinge
2012-02-22 16:56 ` Kevin Buettner
2012-02-22 19:33 ` Simulator testing for sh and sh64 Thomas Schwinge
2012-02-23 0:35 ` Kaz Kojima
2012-02-24 21:38 ` Thomas Schwinge
2012-02-23 19:55 ` Thomas Schwinge
2012-02-23 22:53 ` Kevin Buettner
2012-02-24 11:12 ` Thomas Schwinge
2012-02-23 23:57 ` Kevin Buettner
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=20120229171247.12db9412@mesquite.lan \
--to=kevinb@redhat.com \
--cc=gdb-patches@sourceware.org \
/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