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. 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. > > 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. 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. > 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. -Andi
