On Tue, Nov 13, 2018 at 07:37:27PM +0100, Richard Biener wrote:
> I'd look at doing the instrumentation after var-tracking has run - that is
> what computes the locations in the end. That means instrumenting on late RTL
> after register allocation (and eventually with branch range restrictions in
On November 13, 2018 7:09:15 PM GMT+01:00, Andi Kleen
wrote:
>On Tue, Nov 13, 2018 at 09:03:52AM +0100, Richard Biener wrote:
>> > I even had an earlier version of this that instrumented
>> > assembler output of the compiler with PTWRITE in a separate script,
>> > and it worked fine too.
>>
>> A
On Tue, Nov 13, 2018 at 09:03:52AM +0100, Richard Biener wrote:
> > I even had an earlier version of this that instrumented
> > assembler output of the compiler with PTWRITE in a separate script,
> > and it worked fine too.
>
> Apart from eventually messing up branch range restrictions I guess ;)
On Mon, Nov 12, 2018 at 4:16 AM Andi Kleen wrote:
>
> On Sun, Nov 11, 2018 at 10:06:21AM +0100, Richard Biener wrote:
> > That is, usually debuggers look for a location list of a variable
> > and find, say, %rax. But for ptwrite the debugger needs to
> > examine all active location lists for, say
On Sun, Nov 11, 2018 at 10:06:21AM +0100, Richard Biener wrote:
> That is, usually debuggers look for a location list of a variable
> and find, say, %rax. But for ptwrite the debugger needs to
> examine all active location lists for, say, %rax and figure out
> that it contains the value for variab
On Sun, Nov 11, 2018 at 11:37:57AM -0700, Martin Sebor wrote:
> One other high-level comment: a more powerful interface to
> variable tracing than annotating declarations in the source
> would be to provide either the names of the symbols to trace
> on the command line or in an external file. That
One other high-level comment: a more powerful interface to
variable tracing than annotating declarations in the source
would be to provide either the names of the symbols to trace
on the command line or in an external file. That way tracing
could be enabled for objects and types declared in read-
On Fri, Nov 9, 2018 at 7:18 PM Andi Kleen wrote:
>
> Hi Richard,
>
> On Fri, Nov 09, 2018 at 04:27:22PM +0100, Richard Biener wrote:
> > > Passes bootstrap and test suite on x86_64-linux, also
> > > bootstrapped and tested gcc itself with full -fvartrace
> > > and -fvartrace-locals instrumentation
On 11/04/2018 12:32 AM, Andi Kleen wrote:
From: Andi Kleen
Add a new pass to automatically instrument changes to variables
with the new PTWRITE instruction on x86. PTWRITE writes a 4 or 8 byte
field into an Processor Trace log, which allows log over head
logging of informatin.
This allows to r
Hi Richard,
On Fri, Nov 09, 2018 at 04:27:22PM +0100, Richard Biener wrote:
> > Passes bootstrap and test suite on x86_64-linux, also
> > bootstrapped and tested gcc itself with full -fvartrace
> > and -fvartrace-locals instrumentation.
>
> So how is this supposed to be used? I guess in a
> edit
On Sun, Nov 4, 2018 at 7:33 AM Andi Kleen wrote:
>
> From: Andi Kleen
>
> Add a new pass to automatically instrument changes to variables
> with the new PTWRITE instruction on x86. PTWRITE writes a 4 or 8 byte
> field into an Processor Trace log, which allows log over head
> logging of informatin
From: Andi Kleen
Add a new pass to automatically instrument changes to variables
with the new PTWRITE instruction on x86. PTWRITE writes a 4 or 8 byte
field into an Processor Trace log, which allows log over head
logging of informatin.
This allows to reconstruct how values later, which can be us
From: Andi Kleen
Add a new pass to automatically instrument changes to variables
with the new PTWRITE instruction on x86. PTWRITE writes a 4 or 8 byte
field into an external Processor Trace log.
This allows to reconstruct how values later, which can be useful for
debugging or other analysis of t
13 matches
Mail list logo
