public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Recognize branch instruction on MIPS in gdb.trace/entry-values.exp
Date: Wed, 07 Jan 2015 23:22:00 -0000	[thread overview]
Message-ID: <alpine.LFD.2.11.1501072207140.27020@eddie.linux-mips.org> (raw)
In-Reply-To: <87r3vbuecf.fsf@codesourcery.com>

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

  reply	other threads:[~2015-01-07 23:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-29  8:15 Yao Qi
2014-12-29 23:20 ` Maciej W. Rozycki
2014-12-30 12:34   ` Yao Qi
2014-12-30 14:17     ` Maciej W. Rozycki
2015-01-04  8:42       ` Yao Qi
2015-01-07 23:22         ` Maciej W. Rozycki [this message]
2015-01-08  1:10           ` Yao Qi
2015-01-08  1:24             ` Maciej W. Rozycki
2015-01-08  3:47               ` Yao Qi

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=alpine.LFD.2.11.1501072207140.27020@eddie.linux-mips.org \
    --to=macro@linux-mips.org \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.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).