From: Pedro Alves <pedro@palves.net>
To: Kevin Buettner <kevinb@redhat.com>,
Carl Love via Gdb-patches <gdb-patches@sourceware.org>
Cc: Rogerio Alves <rogealve@br.ibm.com>
Subject: Re: [PATCH] PowerPC: fix for gdb.base/eh_return.exp
Date: Fri, 6 May 2022 22:16:02 +0100 [thread overview]
Message-ID: <70a877cc-2f35-3924-6717-9d519c2730c5@palves.net> (raw)
In-Reply-To: <20220506110826.5e16c8b6@f35-zws-1>
On 2022-05-06 19:08, Kevin Buettner via Gdb-patches wrote:
> Hi Carl,
>
> On Thu, 05 May 2022 13:07:29 -0700
> Carl Love via Gdb-patches <gdb-patches@sourceware.org> wrote:
>
>> PowerPC: fix for gdb.base/eh_return.exp
>>
>> The expect file does a disassembly of function eh2 to get the address of
>> the last instruction of function eh2. The last instruction on PowerPC is
>> followed by three .long entries. This requires a different pattern
>> matching for PowerPC versus other architectures.
>>
>> This patch adds the needed gdb_test_multiple match statement for the
>> PowerPC disassembly code.
>>
>> This patch fixes the one test failure on PowerPC.
>>
>> The patch has been tested on Power 10 and Intel 64.
>> ---
>> gdb/testsuite/gdb.base/eh_return.exp | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/gdb/testsuite/gdb.base/eh_return.exp b/gdb/testsuite/gdb.base/eh_return.exp
>> index df55dbc72da..ce46a3623d9 100644
>> --- a/gdb/testsuite/gdb.base/eh_return.exp
>> +++ b/gdb/testsuite/gdb.base/eh_return.exp
>> @@ -27,6 +27,22 @@ set address -1
>>
>> # Get the address of the last insn in function eh2.
>> gdb_test_multiple "disassemble eh2" "" {
>> + -re "($hex)\[^\r\n\]*blr.*" {
>> + # The dissassebmly on Powerpc looks like:
>> + # Dump of assembler code for function eh2:
>> + # 0x00000000100009e0 <+0>: lis r2,4098
>> + # ...
>> + # 0x0000000010000b04 <+292>: add r1,r1,r10
>> + # 0x0000000010000b08 <+296>: blr
>> + # 0x0000000010000b0c <+300>: .long 0x0
>> + # 0x0000000010000b10 <+304>: .long 0x1000000
>> + # 0x0000000010000b14 <+308>: .long 0x1000180
>> + # End of assembler dump.
>> + #
>> + # Powerpc needs the address for the blr instruction above.
>> + set address $expect_out(1,string)
>> + pass $gdb_test_name
>> + }
>> -re -wrap "($hex)\[^\r\n\]*\r\nEnd of assembler dump." {
>> set address $expect_out(1,string)
>> pass $gdb_test_name
>> --
>
> I'd prefer to see a solution which doesn't explicitly test for PPC's blr
> or any other architecture specific instruction.
>
> It seems to me that the problem results from the .long entries
> following the last executable instruction. My guess is that these
> would be problematic on other architectures too. I think it'd
> be better to write an RE which skips all trailing occurrences of
> $hex\[^\r\n\]*\.long\[^\r\n\]* .
Do you know why those .long are there in the first place? Kind of looks like
data in the middle of text? I wonder whether that's a GDB bug or normal...
next prev parent reply other threads:[~2022-05-06 21:16 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-05 20:07 Carl Love
2022-05-06 18:08 ` Kevin Buettner
2022-05-06 21:16 ` Pedro Alves [this message]
2022-05-06 22:45 ` will schmidt
2022-05-09 19:17 ` [PATCH V2] " Carl Love
2022-05-09 20:57 ` will schmidt
2022-05-10 11:43 ` Pedro Alves
2022-05-11 21:52 ` Carl Love
2022-05-11 21:52 ` [PATCH V3] " Carl Love
2022-05-11 22:48 ` Kevin Buettner
2022-05-12 16:00 ` Carl Love
2022-06-02 16:52 ` Carl Love
2022-06-08 18:32 ` Pedro Alves
2022-06-08 18:51 ` Carl Love
2022-06-09 15:24 ` Carl Love
2022-06-02 17:00 ` [PATCH V4] " Carl Love
2022-06-07 17:54 ` will schmidt
2022-06-08 15:33 ` [PATCH V5] " Carl Love
2022-06-08 15:36 ` Carl Love
2022-06-08 16:29 ` will schmidt
2022-07-13 17:07 ` [Ping] " Carl Love
2022-07-15 13:41 ` Ulrich Weigand
-- strict thread matches above, loose matches on Subject: below --
2022-03-23 17:49 [PATCH] Powerpc " Carl Love
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=70a877cc-2f35-3924-6717-9d519c2730c5@palves.net \
--to=pedro@palves.net \
--cc=gdb-patches@sourceware.org \
--cc=kevinb@redhat.com \
--cc=rogealve@br.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).