Message ID | 87r3vbuecf.fsf@codesourcery.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 19530 invoked by alias); 4 Jan 2015 08:42:21 -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 19513 invoked by uid 89); 4 Jan 2015 08:42:19 -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; Sun, 04 Jan 2015 08:42:16 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1Y7glI-0003Zb-Rl from Yao_Qi@mentor.com for gdb-patches@sourceware.org; Sun, 04 Jan 2015 00:42:12 -0800 Received: from GreenOnly (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.3.224.2; Sun, 4 Jan 2015 00:42:11 -0800 From: Yao Qi <yao@codesourcery.com> To: "Maciej W. Rozycki" <macro@codesourcery.com> CC: <gdb-patches@sourceware.org> Subject: Re: [PATCH] Recognize branch instruction on MIPS in gdb.trace/entry-values.exp References: <1419840861-10723-1-git-send-email-yao@codesourcery.com> <alpine.DEB.1.10.1412292255010.19155@tp.orcam.me.uk> <87zja5uxjk.fsf@codesourcery.com> <alpine.DEB.1.10.1412301401280.19155@tp.orcam.me.uk> Date: Sun, 4 Jan 2015 16:42:08 +0800 In-Reply-To: <alpine.DEB.1.10.1412301401280.19155@tp.orcam.me.uk> (Maciej W. Rozycki's message of "Tue, 30 Dec 2014 14:17:17 +0000") Message-ID: <87r3vbuecf.fsf@codesourcery.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes |
Commit Message
Yao Qi
Jan. 4, 2015, 8:42 a.m. UTC
"Maciej W. Rozycki" <macro@codesourcery.com> writes: >> 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. OK, I'll update the pattern to avoid this... > >> >> 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. I did the tests with the following options on both bare metal and linux targets, -mabi=64 -mabi=32 -mabi=32 -mips16 -mabi=32 -mmicromips and test this on bare metal target only, -mabi=32 -mips16 -mflip-mips16 instructions bal jal jals and jalx are generated in these combinations.
Comments
On Sun, 4 Jan 2015, Yao Qi wrote: > I did the tests with the following options on both bare metal and linux > targets, > > -mabi=64 > -mabi=32 > -mabi=32 -mips16 > -mabi=32 -mmicromips > > and test this on bare metal target only, > > -mabi=32 -mips16 -mflip-mips16 > > instructions bal jal jals and jalx are generated in these combinations. Hmm, JALR used with `-mabi=64' on Linux must have been relaxed to BAL by the linker then; this will happen for in-range calls to a location within the same binary image when requested by the R_MIPS_JALR relocation, produced by GCC automatically where applicable. This is controlled with `-mrelax-pic-calls', so you should still see JALR on n64 Linux with: -mabi=64 -mno-relax-pic-calls You should also see JALR and possibly JALRC on MIPS16 Linux with: -mabi=32 -mips16 -mno-plt where no corresponding branch instruction to relax to is available. And you might see JALRS on microMIPS Linux with: -mabi=32 -mmicromips -mno-plt but I don't think you need to test these unless you really want to. I think BALS would only be observed if JALRS was relaxed, but this linker optimisation is missing. We should expect it to be corrected sometime though and be flexible on matching so that we don't have to update the test case again when other parts of the toolchain are updated. Thanks for the tests you ran, these are enough as far as I am concerned. > diff --git a/gdb/testsuite/gdb.trace/entry-values.exp b/gdb/testsuite/gdb.trace/entry-values.exp > index 6bb0514..50e9636 100644 > --- a/gdb/testsuite/gdb.trace/entry-values.exp > +++ b/gdb/testsuite/gdb.trace/entry-values.exp > @@ -43,6 +43,19 @@ if { [istarget "arm*-*-*"] || [istarget "aarch64*-*-*"] } { > set call_insn "brasl" > } elseif { [istarget "powerpc*-*-*"] } { > set call_insn "bl" > +} elseif { [istarget "mips*-*-*"] } { > + # Skip the delay slot after jump or branch instruction if it has. > + # > + # JUMP (or BRANCH) foo > + # insn1 > + # insn2 > + # > + # All the jump or branch instructions except jalrc (jal, jals, jalx, > + # jalr, jalrs, bal, bals) have the delay slot, so program goes to > + # insn2 when it returns from foo. How about: # Skip the delay slot after the instruction used to make a call # (which can be a jump or a branch) if it has one. # # JUMP (or BRANCH) foo # insn1 # insn2 # # Most MIPS instructions used to make calls have a delay slot. # These include JAL, JALS, JALX, JALR, JALRS, BAL and BALS. # In this case the program continues from `insn2' when `foo' # returns. The only exception is JALRC, in which case execution # resumes from `insn1' instead. ? Overall I'd prefer MIPS instructions to be spelled out capitalised in our documentation for consistency with hardware documentation. This makes them more prominent in text and also avoids confusing them with common words such as in `AND' vs `and'. The only exception are quoted pieces of assembly code where the language specifies mnemonics as lowercase strings. > If it is jalrc, set > + # RETURNED_FROM_FOO to insn1, otherwise set RETURNED_FROM_FOO to > + # insn2. > + set call_insn {jalrc|[jb]al[sxr]*[ \t][^\r\n]+\r\n} OK, this should work. I have a minor nit yet: `[sxr]?' will be more accurate than `[sxr]*', you want to see the letter at most once. The former regexp will likely interpret faster too. I'm fine with your change with these updates applied, or please feel free to post another proposal if you disagree with any of my suggestions and want to discuss them further. Thanks for your contribution. Maciej
"Maciej W. Rozycki" <macro@linux-mips.org> writes: > Overall I'd prefer MIPS instructions to be spelled out capitalised in our > documentation for consistency with hardware documentation. This makes > them more prominent in text and also avoids confusing them with common > words such as in `AND' vs `and'. The only exception are quoted pieces of > assembly code where the language specifies mnemonics as lowercase strings. > OK, that is fine to me. >> If it is jalrc, set >> + # RETURNED_FROM_FOO to insn1, otherwise set RETURNED_FROM_FOO to >> + # insn2. >> + set call_insn {jalrc|[jb]al[sxr]*[ \t][^\r\n]+\r\n} > > OK, this should work. I have a minor nit yet: `[sxr]?' will be more > accurate than `[sxr]*', you want to see the letter at most once. The > former regexp will likely interpret faster too. We want to match JALRS, so [sxr]* is needed here.
On Thu, 8 Jan 2015, Yao Qi wrote: > >> If it is jalrc, set > >> + # RETURNED_FROM_FOO to insn1, otherwise set RETURNED_FROM_FOO to > >> + # insn2. > >> + set call_insn {jalrc|[jb]al[sxr]*[ \t][^\r\n]+\r\n} > > > > OK, this should work. I have a minor nit yet: `[sxr]?' will be more > > accurate than `[sxr]*', you want to see the letter at most once. The > > former regexp will likely interpret faster too. > > We want to match JALRS, so [sxr]* is needed here. Fair enough, the pattern matches more than necessary, but there are no MIPS instructions it would match that it shouldn't, so let's keep your proposal as it is for simplicity. I have no further concerns, thanks for your work and for getting through this review. Maciej
diff --git a/gdb/testsuite/gdb.trace/entry-values.exp b/gdb/testsuite/gdb.trace/entry-values.exp index 6bb0514..50e9636 100644 --- a/gdb/testsuite/gdb.trace/entry-values.exp +++ b/gdb/testsuite/gdb.trace/entry-values.exp @@ -43,6 +43,19 @@ if { [istarget "arm*-*-*"] || [istarget "aarch64*-*-*"] } { set call_insn "brasl" } elseif { [istarget "powerpc*-*-*"] } { set call_insn "bl" +} elseif { [istarget "mips*-*-*"] } { + # Skip the delay slot after jump or branch instruction if it has. + # + # JUMP (or BRANCH) foo + # insn1 + # insn2 + # + # All the jump or branch instructions except jalrc (jal, jals, jalx, + # jalr, jalrs, bal, bals) have the delay slot, so program goes to + # insn2 when it returns from foo. If it is jalrc, set + # RETURNED_FROM_FOO to insn1, otherwise set RETURNED_FROM_FOO to + # insn2. + set call_insn {jalrc|[jb]al[sxr]*[ \t][^\r\n]+\r\n} } else { set call_insn "call" }