public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Bruno Larsen <blarsen@redhat.com>
To: Carl Love <cel@us.ibm.com>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Cc: Will Schmidt <will_schmidt@vnet.ibm.com>
Subject: Re: [PATCH] Powerpc fix for gdb.base/unwind-on-each-insn.exp
Date: Fri, 4 Nov 2022 14:11:10 +0100	[thread overview]
Message-ID: <c64b8f4b-6575-5c36-ce9c-31ec62265bce@redhat.com> (raw)
In-Reply-To: <e8e84dd4854917cdec2eaae108d7045dcf24700a.camel@us.ibm.com>

On 02/11/2022 18:03, Carl Love wrote:
> GDB maintainers:
>
> The test gdb.base/unwind-on-each-insn.exp was recently added.  The
> patch generates about 575 failures on PowerPC.  The issue is the code
> to determine the number of lines in function foo does not work
> correctly on PowerPC.  As a result, the test doesn't stop the frame
> checks when it reaches the end of the function.  The test keeps going
> past the end of the function which results in the errors and warnings.
>
> This patch adds code to skip lines with the .long specifier in the
> disassembly output that follow the last instruction in the function.
> With this fix, the test correctly determines the number of lines in
> function foo.
>
> Please let me know if the patch is acceptable for mainline.  Thanks.
>
>                     Carl Love
>
> --------------------------------------------
> Powerpc fix for gdb.base/unwind-on-each-insn.exp
>
> The test disassembles function foo and searches for the line
> "End of assembler dump" to determing the last address in the function.  The
> assumption is the last instruction will be given right before the line
> "End of assembler dump".  This assumption fails on PowerPC.
>
> The PowerPC disassembly of the function foo looks like:
>   Dump of assembler code for function foo:
> #  => 0x00000000100006dc <+0>:     std     r31,-8(r1)
> #     0x00000000100006e0 <+4>:     stdu    r1,-48(r1)
> #     0x00000000100006e4 <+8>:     mr      r31,r1
> #     0x00000000100006e8 <+12>:    nop
> #     0x00000000100006ec <+16>:    addi    r1,r31,48
> #     0x00000000100006f0 <+20>:    ld      r31,-8(r1)
> #     0x00000000100006f4 <+24>:    blr
> #     0x00000000100006f8 <+28>:    .long 0x0
> #     0x00000000100006fc <+32>:    .long 0x0
> #     0x0000000010000700 <+36>:    .long 0x1000180
> #     End of assembler dump.
>
> The blr instruction is the last instruction in function foo.  The lines
> with .long following the blr instruction need to be ignored.
>
> This patch adds a new condition to the gdb_test_multiple "disassemble foo"
> test to ignore the lines with the .long.
>
> The patch has been tested on PowerPC and Intel X86-64.

Thanks, this looks good.

Reviewed-By: Bruno Larsen <blarsen@redhat.com>

Cheers,
Bruno

> ---
>   .../gdb.base/unwind-on-each-insn.exp          | 22 +++++++++++++++++++
>   1 file changed, 22 insertions(+)
>
> diff --git a/gdb/testsuite/gdb.base/unwind-on-each-insn.exp b/gdb/testsuite/gdb.base/unwind-on-each-insn.exp
> index 3b48805cff8..d8863ad2895 100644
> --- a/gdb/testsuite/gdb.base/unwind-on-each-insn.exp
> +++ b/gdb/testsuite/gdb.base/unwind-on-each-insn.exp
> @@ -75,6 +75,24 @@ gdb_continue_to_breakpoint "enter foo"
>   
>   # Figure out the range of addresses covered by this function.
>   set last_addr_in_foo ""
> +
> +# The disassembly of foo on PowerPC looks like:
> +#     Dump of assembler code for function foo:
> +#  => 0x00000000100006dc <+0>:     std     r31,-8(r1)
> +#     0x00000000100006e0 <+4>:     stdu    r1,-48(r1)
> +#     0x00000000100006e4 <+8>:     mr      r31,r1
> +#     0x00000000100006e8 <+12>:    nop
> +#     0x00000000100006ec <+16>:    addi    r1,r31,48
> +#     0x00000000100006f0 <+20>:    ld      r31,-8(r1)
> +#     0x00000000100006f4 <+24>:    blr
> +#     0x00000000100006f8 <+28>:    .long 0x0
> +#     0x00000000100006fc <+32>:    .long 0x0
> +#     0x0000000010000700 <+36>:    .long 0x1000180
> +#     End of assembler dump.
> +#
> +# The last instruction in function foo is blr.  Need to ignore the .long
> +# entries following the blr instruction.
> +
>   gdb_test_multiple "disassemble foo" "" {
>       -re "^disassemble foo\r\n" {
>   	exp_continue
> @@ -84,6 +102,10 @@ gdb_test_multiple "disassemble foo" "" {
>   	exp_continue
>       }
>   
> +    -re "^...($hex) \[<>+0-9:\s\t\]*\.long\[\s\t\]*\[^\r\n\]*\r\n" {
> +	exp_continue
> +    }
> +
>       -re "^...($hex) \[^\r\n\]+\r\n" {
>   	set last_addr_in_foo $expect_out(1,string)
>   	exp_continue


      parent reply	other threads:[~2022-11-04 13:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-02 17:03 Carl Love
2022-11-04 13:09 ` Ulrich Weigand
2022-11-04 13:11 ` Bruno Larsen [this message]

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=c64b8f4b-6575-5c36-ce9c-31ec62265bce@redhat.com \
    --to=blarsen@redhat.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=cel@us.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=will_schmidt@vnet.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).