Recognize branch instruction on MIPS in gdb.trace/entry-values.exp

  "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.
  

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