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
>
next prev parent 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