This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/3] Add a pass to automatically add ptwrite instrumentation


On Mon, Nov 12, 2018 at 4:16 AM Andi Kleen <ak@linux.intel.com> 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, %rax and figure out
> > that it contains the value for variable 'a'?
>
> In dwarf output you end up with a list of
>
> start-IP...stop-IP <dwarf scope>...  variable locations
>
> Both the original load/store and PTWRITE are in the same scope,
> and the debugger just looks it up based on the IP,
> so it all works without any extra modifications.

Yes, that's how I thought it would work.

> 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 ;)

> >
> > When there isn't any such relation between the ptwrite stored
> > value and any variable the ptwrite is useless, right?
>
> A programmer might still be able to make use of it
> based on the context or the order.

OK.

> e.g. if you don't instrument everything, but only specific
> variables, or you only instrument arguments and returns or
> similar then it could be still useful just based on the IP->symbol
> resolution. If you instrument too many things yes it will be
> hard to use without debug info resolution.

Did you gather any statistics on how many ptwrite instructions
that are generated by your patch are not covered by any
location range & expr?  I assume ptwrite is writing from register
input only so you probably should avoid instrumenting writes
of constants (will require an extra register)?

How does the .text size behave say for cc1 when you enable
the various granularities of instrumentation?  How many
ptwrite instructions are there per 100 regular instructions?

> > I hope you don't mind if this eventually slips to GCC 10 given
> > as you say there is no HW available right now.  (still waiting
> > for a CPU with CET ...)
>
> :-/
>
> Actually there is.  Gemini Lake Atom Hardware with Goldmont Plus
> is shipping for some time and you can buy them.

Ah, interesting.

Can we get an updated patch based on my review?

I still think we should eventually move the pass later and somehow
avoid instrumenting places we'll not have any meaningful locations
in the debug info - if only to reduce required trace bandwith.

Thanks,
Richard.

> -Andi


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]