Message ID | 1419840861-10723-1-git-send-email-yao@codesourcery.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 21943 invoked by alias); 29 Dec 2014 08:15:13 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 21930 invoked by uid 89); 29 Dec 2014 08:15:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Dec 2014 08:15:10 +0000 Received: from svr-orw-fem-06.mgc.mentorg.com ([147.34.97.120]) by relay1.mentorg.com with esmtp id 1Y5VTn-0003p5-Oq from Yao_Qi@mentor.com for gdb-patches@sourceware.org; Mon, 29 Dec 2014 00:15:07 -0800 Received: from qiyao.dyndns.org.com (147.34.91.1) by SVR-ORW-FEM-06.mgc.mentorg.com (147.34.97.120) with Microsoft SMTP Server id 14.3.224.2; Mon, 29 Dec 2014 00:15:07 -0800 From: Yao Qi <yao@codesourcery.com> To: <gdb-patches@sourceware.org> Subject: [PATCH] Recognize branch instruction on MIPS in gdb.trace/entry-values.exp Date: Mon, 29 Dec 2014 16:14:21 +0800 Message-ID: <1419840861-10723-1-git-send-email-yao@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes |
Commit Message
Yao Qi
Dec. 29, 2014, 8:14 a.m. UTC
The test entry-values.exp doesn't recognize the call instruction "jal" on MIPS, so this patch sets call_insn "jal" first. Currently, we assume the next instruction address of call instruction is the address returned from foo, however it is not correct on MIPS which has delay slot. We extend variable call_insn to match one instruction after jal, so that $returned_from_foo is correct on MIPS. All tests in entry-values.exp are PASS. gdb/testsuite: 2014-12-29 Yao Qi <yao@codesourcery.com> * gdb.trace/entry-values.exp: Set call_insn for MIPS target. --- gdb/testsuite/gdb.trace/entry-values.exp | 10 ++++++++++ 1 file changed, 10 insertions(+)
Comments
On Mon, 29 Dec 2014, Yao Qi wrote: > The test entry-values.exp doesn't recognize the call instruction "jal" > on MIPS, so this patch sets call_insn "jal" first. > > Currently, we assume the next instruction address of call instruction > is the address returned from foo, however it is not correct on MIPS > which has delay slot. We extend variable call_insn to match one > instruction after jal, so that $returned_from_foo is correct on MIPS. What's the semantics of the test case and the changes you're making? I'm asking because the MIPS architecture has several instructions used to make procedure calls, depending on the ISA and ABI selected, and also compiler options. Besides JAL these instructions include JALS, JALX, JALR, JALRC, JALRS, BAL and BALS. It looks to me you need to modify the pattern here to take these into account; JALRC does not have a delay slot. > All tests in entry-values.exp are PASS. Which target and ABI(s) did you ran your testing on? Please try at least these: o32/MIPS, o32/MIPS16, o32/microMIPS, n64 on a Linux and a bare-metal target each; testing o32/MIPS16 with the `-mflip-mips16' GCC option too will be appreciated. These combinations should trigger some (although not all) of the other possible instructions. Maciej
"Maciej W. Rozycki" <macro@codesourcery.com> writes: > What's the semantics of the test case and the changes you're making? > dwarf assembler is used to generate debug info with DW_TAG_GNU_call_site and DW_TAG_GNU_call_site_parameter to exercise GDB. The change I am making in this patch is to recognize branch instruction on MIPS, so that we can compute the address returned from foo, and fill it in the generated debug info. > I'm asking because the MIPS architecture has several instructions used to > make procedure calls, depending on the ISA and ABI selected, and also > compiler options. Besides JAL these instructions include JALS, JALX, > JALR, JALRC, JALRS, BAL and BALS. It looks to me you need to modify the > pattern here to take these into account; JALRC does not have a delay slot. > I'll update the pattern to {jalrc|(?:jal|bal)[^\r\n]+\r\n} >> All tests in entry-values.exp are PASS. > > Which target and ABI(s) did you ran your testing on? Please try at least > these: o32/MIPS, o32/MIPS16, o32/microMIPS, n64 on a Linux and a > bare-metal target each; testing o32/MIPS16 with the `-mflip-mips16' GCC > option too will be appreciated. These combinations should trigger some > (although not all) of the other possible instructions. To avoid of misunderstanding, let me map them to the following concrete gcc options (I don't find -mabi=o32 nor -mabi=n64 in https://gcc.gnu.org/onlinedocs/gcc/MIPS-Options.html), -mabi=32 -mabi=32 -mips16 -mabi=32 -mips16 -mflip-mips16 -mabi=32 -mmicromips -mabi=64 on both linux and bare-metal target are they what you want?
On Tue, 30 Dec 2014, Yao Qi wrote: > > What's the semantics of the test case and the changes you're making? > > > > dwarf assembler is used to generate debug info with DW_TAG_GNU_call_site > and DW_TAG_GNU_call_site_parameter to exercise GDB. The change I am > making in this patch is to recognize branch instruction on MIPS, so that > we can compute the address returned from foo, and fill it in the > generated debug info. Ah, OK. > > I'm asking because the MIPS architecture has several instructions used to > > make procedure calls, depending on the ISA and ABI selected, and also > > compiler options. Besides JAL these instructions include JALS, JALX, > > JALR, JALRC, JALRS, BAL and BALS. It looks to me you need to modify the > > pattern here to take these into account; JALRC does not have a delay slot. > > > > I'll update the pattern to {jalrc|(?:jal|bal)[^\r\n]+\r\n} I think {jalrc|[jb]al[^\r\n]+\r\n} will be a little bit more efficient, but please make sure too that the right-hand side branch does not swallow `jalrc' with its following instruction by greedy matching: "An RE consisting of two or more branches connected by the | operator prefers longest match." (from the TCL Reference Manual) -- so I think you'll have to modify your regexp further yet. > >> All tests in entry-values.exp are PASS. > > > > Which target and ABI(s) did you ran your testing on? Please try at least > > these: o32/MIPS, o32/MIPS16, o32/microMIPS, n64 on a Linux and a > > bare-metal target each; testing o32/MIPS16 with the `-mflip-mips16' GCC > > option too will be appreciated. These combinations should trigger some > > (although not all) of the other possible instructions. > > To avoid of misunderstanding, let me map them to the following concrete gcc > options (I don't find -mabi=o32 nor -mabi=n64 in > https://gcc.gnu.org/onlinedocs/gcc/MIPS-Options.html), > > -mabi=32 > -mabi=32 -mips16 > -mabi=32 -mips16 -mflip-mips16 > -mabi=32 -mmicromips > -mabi=64 on both linux and bare-metal target > > are they what you want? Yes, except I meant both Linux and bare-metal across all the variations, not n64 only (missing comma after `n64' in my original sentence). Here n64 matters as it covers PIC calling sequences. Maciej
diff --git a/gdb/testsuite/gdb.trace/entry-values.exp b/gdb/testsuite/gdb.trace/entry-values.exp index 6bb0514..bf395f7 100644 --- a/gdb/testsuite/gdb.trace/entry-values.exp +++ b/gdb/testsuite/gdb.trace/entry-values.exp @@ -43,6 +43,16 @@ if { [istarget "arm*-*-*"] || [istarget "aarch64*-*-*"] } { set call_insn "brasl" } elseif { [istarget "powerpc*-*-*"] } { set call_insn "bl" +} elseif { [istarget "mips*-*-*"] } { + # Skip one instruction after jal which is the delay slot. + # + # jal foo + # insn1 + # insn2 + # + # program goes to insn2 when it returns from foo. We should set + # RETURNED_FROM_FOO to insn2. + set call_insn "jal\[^\r\n\]+\r\n" } else { set call_insn "call" }