This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Recognize branch instruction on MIPS in gdb.trace/entry-values.exp
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 7 Jan 2015 23:22:22 +0000 (GMT)
- Subject: Re: [PATCH] Recognize branch instruction on MIPS in gdb.trace/entry-values.exp
- Authentication-results: sourceware.org; auth=none
- References: <1419840861-10723-1-git-send-email-yao at codesourcery dot com> <alpine dot DEB dot 1 dot 10 dot 1412292255010 dot 19155 at tp dot orcam dot me dot uk> <87zja5uxjk dot fsf at codesourcery dot com> <alpine dot DEB dot 1 dot 10 dot 1412301401280 dot 19155 at tp dot orcam dot me dot uk> <87r3vbuecf dot fsf at codesourcery dot 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