public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: Re: [PATCH] [gdb/testsuite] Add gdb.base/unwind-on-each-insn-{amd64, i386}.exp
Date: Thu, 26 Jan 2023 17:21:25 +0100	[thread overview]
Message-ID: <a09ee5b7-9f46-735d-988d-0e25a7baba19@suse.de> (raw)
In-Reply-To: <20230125200910.29700-1-tdevries@suse.de>

On 1/25/23 21:09, Tom de Vries via Gdb-patches wrote:
> The gcc 4.4.x (and earlier) compilers had the problem that the unwind info in
> the epilogue was inaccurate.
> 
> In order to work around this in gdb, epilogue unwinders were added with a
> higher priority than the dwarf unwinders in the amd64 and i386 targets:
> - amd64_epilogue_frame_unwind, and
> - i386_epilogue_frame_unwind.
> 
> Subsequently, the epilogue unwind info problem got fixed in gcc 4.5.0.
> 
> However, the epilogue unwinders prevented gdb from taking advantage of the
> fixed epilogue unwind info, so the scope of the epilogue unwinders was
> limited, bailing out for gcc >= 4.5.0.
> 
> There was no regression test added for this preference scheme, so if we now
> declare epilogue unwind info from all gcc versions as trusted, no test will
> start failing.
> 
> Fix this by adding an amd64 and i386 regression test for this.
> 
> I have no gcc 4.4.x lying around, so I fabricated the assembly files by:
> - commenting out some .cfi directives to break the epilogue unwind info, and
> - hand-editing the producer info to 4.4.7 to activate the fix.
> 
> Tested on x86_64-linux, target boards unix/{-m64,-m32}.
> ---
>   .../gdb.base/unwind-on-each-insn-amd64.exp    |  42 +++
>   .../gdb.base/unwind-on-each-insn-amd64.s      | 263 ++++++++++++++++++
>   .../gdb.base/unwind-on-each-insn-i386.exp     |  39 +++
>   .../gdb.base/unwind-on-each-insn-i386.s       | 262 +++++++++++++++++
>   .../gdb.base/unwind-on-each-insn.exp          | 160 +----------
>   .../gdb.base/unwind-on-each-insn.exp.tcl      | 180 ++++++++++++
>   6 files changed, 792 insertions(+), 154 deletions(-)
>   create mode 100644 gdb/testsuite/gdb.base/unwind-on-each-insn-amd64.exp
>   create mode 100644 gdb/testsuite/gdb.base/unwind-on-each-insn-amd64.s
>   create mode 100644 gdb/testsuite/gdb.base/unwind-on-each-insn-i386.exp
>   create mode 100644 gdb/testsuite/gdb.base/unwind-on-each-insn-i386.s
>   create mode 100644 gdb/testsuite/gdb.base/unwind-on-each-insn.exp.tcl

I've fixed some nits and pushed this.

I did wonder about eliminating commonality between 
unwind-on-each-insn-i386.exp and unwind-on-each-insn-amd64.exp, but 
decided it was not worth the trouble.

Thanks,
- Tom

  reply	other threads:[~2023-01-26 16:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-25 20:09 [PATCH] [gdb/testsuite] Add gdb.base/unwind-on-each-insn-{amd64,i386}.exp Tom de Vries
2023-01-26 16:21 ` Tom de Vries [this message]
2023-01-26 18:22   ` [PATCH] [gdb/testsuite] Add gdb.base/unwind-on-each-insn-{amd64, i386}.exp Tom Tromey
2023-01-27 20:50     ` Tom de Vries

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=a09ee5b7-9f46-735d-988d-0e25a7baba19@suse.de \
    --to=tdevries@suse.de \
    --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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).