Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 1 Nov 2019 11:06:11 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     Mike Leach <mike.leach@linaro.org>
Cc:     Leo Yan <leo.yan@linaro.org>,
        Adrian Hunter <adrian.hunter@intel.com>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Borislav Petkov <bp@alien8.de>,
        "H . Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
        Jiri Olsa <jolsa@redhat.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Mathieu Poirier <mathieu.poirier@linaro.org>,
        Will Deacon <will@kernel.org>, linux-kernel@vger.kernel.org,
        x86@kernel.org
Subject: Re: [PATCH RFC 1/6] perf/x86: Add perf text poke event
Message-ID: <20191101100611.GV4131@hirez.programming.kicks-ass.net>
References: <20191025130000.13032-1-adrian.hunter@intel.com>
 <20191025130000.13032-2-adrian.hunter@intel.com>
 <20191030104747.GA21153@leoy-ThinkPad-X240s>
 <20191030124659.GQ4114@hirez.programming.kicks-ass.net>
 <20191030141950.GB21153@leoy-ThinkPad-X240s>
 <20191030162325.GT4114@hirez.programming.kicks-ass.net>
 <20191031073136.GC21153@leoy-ThinkPad-X240s>
 <CAJ9a7VgZH7g=rFDpKf=FzEcyBVLS_WjqbrqtRnjOi7WOY4st+w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAJ9a7VgZH7g=rFDpKf=FzEcyBVLS_WjqbrqtRnjOi7WOY4st+w@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Oct 31, 2019 at 12:29:15PM +0000, Mike Leach wrote:
> On Thu, 31 Oct 2019 at 07:31, Leo Yan <leo.yan@linaro.org> wrote:

> > > Since all instructions (with the possible exception of RET) are
> > > unconditional branch instructions: NOP, JMP, CALL. It makes no read
> > > difference to the argument below.
> > >
> > > ( I'm thinking RET might be special in that it reads the return address
> > > from the stack and therefore must emit the whole IP into the stream, as
> > > we cannot know the stack state )
> >
> > To be honest, I don't have knowledge what's the exactly format for 'ret'
> > in CoreSight trace; so would like to leave this to Mike.
> >
> 
> For ETM trace we do not have to output the entire address into he stream if:
> - address compression allows us to emit only the changed ls bit from the
> last address.
> - the address is identical to one of the last three addresses emitted ( we
> just emit a ‘same address encoding’
> - we are using return stack compression and the address is top of the
> return stack (we emit nothing and the decoder gets the address from its own
> mode, of the return stack)

Cute. I don't actually know what PT does, but I figured there had to at
least be the option to provide more information.