Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Marcin Kościelnicki" <koriakin@0x04.net>
To: Antoine Tremblay <antoine.tremblay@ericsson.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb.trace: Move more target dependencies to trace-support.exp
Date: Fri, 19 Feb 2016 15:18:00 -0000	[thread overview]
Message-ID: <56C7323C.4050707@0x04.net> (raw)
In-Reply-To: <wwokmvqwpwpn.fsf@ericsson.com>

On 19/02/16 16:05, Antoine Tremblay wrote:
>
> Marcin Kościelnicki writes:
>
>> While groveling through the old PPC64 tracepoint support patch, I've
>> noticed a few target dependencies in the testsuite that both me and
>> Antoine missed for s390 and ARM tracepoints, respectively.  This patch
>> moves them all to one place, so that anyone working on a new target
>> will hopefully see the whole set of needed changes.
>
> Thanks for this, it seems I indeed had missed a few, it also fixes
> another issue in the arm tracepoints were I was using is_aarch32_target
> rather then istarget[*arm*].
>
> It's much more clear like that.
>
>>
>> I've also removed a check for fast tracepoint support in ftrace.exp -
>> it used hardcoded targets and wasn't doing anything useful anyway,
>> since unsupported architectures blow up on link due to missing
>> the IPA library before they ever get to that check.
>>
>
> Maybe this should be another patch ? , Obvious ?

Very well, I'll cut it up.
>
>> For some strange reason, the call_insn setting code already knew about
>> arm, powerpc, s390, and mips - I went ahead and added the remaining
>> information about those.  I'm not particularly sure if I got mips right,
>> but that won't matter anyway until someone actually writes tracepoint
>> support for that.
>>
>> In addition, the PPC64 tracepoint patch added \y at the end of the call_insn
>> pattern - without that, it embarassed itself and matched the 'bl' in
>> "Dump of assem*bl*er code for function" as the powerpc call opcode.  Since
>> that sounds like a generally good idea, I've added \y before and after
>> call_insn for every target.  As a result, I had to change x86_64's mnemonic
>> to 'callq'.
>>
>
> Also this could be another patch ?

Likewise.
>
>> Tested on x86_64, i386, ppc, ppc64, ppc64le, s390, s390x.  Would be good
>> to test it on aarch64.
>>
>
>
>> diff --git a/gdb/testsuite/lib/trace-support.exp b/gdb/testsuite/lib/trace-support.exp
>> index f593c43..829786b 100644
>> --- a/gdb/testsuite/lib/trace-support.exp
>> +++ b/gdb/testsuite/lib/trace-support.exp
>> @@ -20,26 +20,99 @@
>>
>>
>>   #
>> -# Program counter / stack pointer / frame pointer for supported targets.
>> -# Used in many tests, kept here to avoid duplication.
>> +# Target-specific information.  Used in many tests, kept here
>> +# to avoid duplication and make it easier to add a new target.
>>   #
>>
>>   if [is_amd64_regs_target] {
>> +    # Frame pointer.
>>       set fpreg "rbp"
>> +    # Stack pointer.
>>       set spreg "rsp"
>> +    # Program counter.
>>       set pcreg "rip"
>> +    # How to collect the first argument to a function.  Used to test
>> +    # register usage in tracepoint conditions.
>> +    set arg0exp "\$rdi"
>> +    # The mnemonic of the usual, unconditional call instruction.
>> +    set call_insn "callq"
>> +    # Number of the PC register.
>> +    set pcnum 16
>> +    # Number of any GPR (it's supposed not to be some register that's not
>> +    # collected by default).
>> +    set gpr0num 0
>>   } elseif [is_x86_like_target] {
>>       set fpreg "ebp"
>>       set spreg "esp"
>>       set pcreg "eip"
>> +    set arg0exp "*(int *) (\$ebp + 8)"
>> +    set call_insn "call"
>> +    set pcnum 8
>> +    set gpr0num 0
>>   } elseif [is_aarch64_target] {
>>       set fpreg "x29"
>>       set spreg "sp"
>>       set pcreg "pc"
>> +    set arg0exp "\$x0"
>> +    set call_insn "bl"
>> +    set pcnum 32
>> +    set gpr0num 0
>> +} elseif [istarget "arm*-*-*"]  {
>> +    set fpreg "r11"
>
> There is no fp as far as I can tell looking at arm aapcs maybe we can
> use sp here ? It's just to collect a register that has a value in the
> tests.

There isn't really a fp according to s390 ABI either, but r11 is what 
gcc uses when it uses a frame pointer (coincidentally for both s390 and 
arm).  I figured I'd play it safe, but might not be necessary.

>
>> +    set spreg "r13"
>
> Need to use sp here, as r13 is not defined in arm-core.xml, using r13
> causes a 'r13' is a user-register; GDB cannot yet trace user-register
> contents. error when collecting.
>
>> +    set pcreg "r15"
>
> Use pc here for the same reasons as above.

Whoops, thanks for noticing that.
>
>> +    set arg0exp "\$r0"
>> +    set call_insn "bl"
>> +    set pcnum 15
>> +    set gpr0num 0
>
> Also in general since arm tracepoints are not there yet, this should be
> part of my tracepoint patch I think, so you can ommit it here and I will
> add it.

Alright, I'll drop that part and leave it to you.
>
>> +} elseif [istarget "powerpc*-*-*"] {
>> +    set fpreg "r31"
>> +    set spreg "r1"
>> +    set pcreg "pc"
>> +    set arg0exp "\$r3"
>> +    set call_insn "bl"
>> +    set pcnum 64
>> +    set gpr0num 0
>> +} elseif [istarget "s390*-*-*"] {
>> +    set fpreg "r11"
>> +    set spreg "r15"
>> +    set pcreg "pc"
>> +    set arg0exp "\$r2"
>> +    set call_insn "brasl"
>> +    # Strictly speaking, this is PSWA, not PC.
>> +    set pcnum 1
>> +    set gpr0num 2
>> +} elseif { [istarget "mips*-*-*"] } {
>> +    set fpreg "s8"
>> +    set spreg "sp"
>> +    set pcreg "pc"
>> +    set arg0exp "\$a0"
>> +    # 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.
>> +    set call_insn {jalrc|[jb]al[sxr]*[ \t][^\r\n]+\r\n}
>> +    set pcnum 37
>> +    set gpr0num 0
>>   } else {
>> +    # Defaults.  Probably won't work, but we don't want to error out
>> +    # here on unsupported platforms, since this file is imported to check
>> +    # for supported platforms in the first place.
>>       set fpreg "fp"
>>       set spreg "sp"
>>       set pcreg "pc"
>> +    set arg0exp "\$a0"
>> +    set call_insn "call"
>> +    set pcnum -1
>> +    set gpr0num -1
>>   }
>>
>>   #
>
> Otherwise I've tested this on arm with the sp/fp/pc changes and the
> tracepoint patch , and it passes tests except for collecting some
> registers locals but I think this is unrelated and will investigate.
>
> Thanks,
> Antoine
>


  reply	other threads:[~2016-02-19 15:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-19 12:23 Marcin Kościelnicki
2016-02-19 15:05 ` Antoine Tremblay
2016-02-19 15:18   ` Marcin Kościelnicki [this message]
2016-02-20 14:02     ` [PATCH 1/3] " Marcin Kościelnicki
2016-02-20 14:02       ` [PATCH 3/3] gdb.trace: Remove unnecessary target check from ftrace.exp Marcin Kościelnicki
2016-02-25 14:22         ` Pedro Alves
2016-02-25 15:12           ` Marcin Kościelnicki
2016-02-20 14:02       ` [PATCH 2/3] gdb.trace: Surround $call_insn with \y in entry-values.exp Marcin Kościelnicki
2016-02-25 14:19         ` Pedro Alves
2016-02-25 15:12           ` Marcin Kościelnicki
2016-02-25 13:45 ` [PATCH] gdb.trace: Move more target dependencies to trace-support.exp Pedro Alves

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=56C7323C.4050707@0x04.net \
    --to=koriakin@0x04.net \
    --cc=antoine.tremblay@ericsson.com \
    --cc=gdb-patches@sourceware.org \
    /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